Subject: [TLS] A side meeting on OpenSSL's plans about QUIC

From: "Salz, Rich" <[email-masked]>
Date: Tue, 2 Nov 2021 18:12:31 +0000

As you might know, the OpenSSL Management Committee (OMC) has released their requirements for upcoming releases [1].  It has been met with a great deal of community pushback, some of which I summarized [2].

A group of us are organizing a side meeting on Weds 16:30-20:00 UTC. You can find the logistics here [3]. Agenda and moderator will be posted soon. The meeting will be recorded.

I know this is cross-posted to two very active lists. Please take care when replying, or save it for the meeting :)

[1] https://www.mail-archive.com/[email-masked]/msg02585.html
[2] https://mta.openssl.org/pipermail/openssl-project/2021-October/002777.html
[3] https://trac.ietf.org/trac/ietf/meeting/wiki/112sidemeetings#point3

---

From: Robin MARX <[email-masked]>
Date: Wed, 3 Nov 2021 11:12:00 +0100

Hello Rich,

I'm wondering if you could give a bit more details about the expected
outcome of this meeting?

IIUC, most people in the QUIC wg at least seem to be of the same opinion
that the OpenSSL plans are bad; I'm not sure IETF people (and even most
other QUIC implementers/users) need (more) convincing of this/repeating of
arguments?
On the other hand, there doesn't seem to be an *active* effort to include
OpenSSL people in the meeting (as mentioned on the quicdev slack yesterday).

As such, I'm wondering what this potential echo-chamber aims to accomplish?
Prepare an "official statement" of sorts? Initiate a more formal liaison
relationship with the OMC? Is it the place of the IETF to "tell" other
projects what to do?
Ratify the switch to quictls and discuss plans for long-term maintenance?
Discuss the future of TLS use in QUIC v2?

Having a more concrete grasp on the goals would help me at least to better
prepare for this potentially crucial meeting.

Practical note for others: the time of the meeting seems to have changed
yesterday, make sure you update your agendas (the timing in the trac seems
correct/consistent with the changed ics).

Thanks and with best regards,
Robin

On Tue, 2 Nov 2021 at 19:13, Salz, Rich <rsalz=[email-masked]>
wrote:

> As you might know, the OpenSSL Management Committee (OMC) has released
> their requirements for upcoming releases [1].  It has been met with a great
> deal of community pushback, some of which I summarized [2].
>
>
>
> A group of us are organizing a side meeting on Weds 16:30-20:00 UTC. You
> can find the logistics here [3]. Agenda and moderator will be posted soon.
> The meeting will be recorded.
>
>
>
> I know this is cross-posted to two very active lists. Please take care
> when replying, or save it for the meeting :)
>
>
>
> [2]
> https://mta.openssl.org/pipermail/openssl-project/2021-October/002777.html
>

-- 

dr. Robin Marx
Postdoc researcher - Web protocols
Expertise centre for Digital Media

*Cellphone *+32(0)497 72 86 94

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 Nov 2021 13:46:37 +0000

*   I'm wondering if you could give a bit more details about the expected outcome of this meeting?

I have no plan, let’s see what the community thinks. (And this is not just me, this started with some people reaching out to me.) Here are some potential outcomes in my view:

  *   People get a better understanding of what OpenSSL plans are.
  *   People tell their company what is happening, and encourage their company to give input to OpenSSL
  *   People rise up, light torches, and storm OpenSSL Headquarters
  *   People offer suggestions about quictls
  *   People talk about a possible perma-fork
Not all of those are equally likely, of course.

I don’t think “echo chamber” is the right way to think of it. Sometimes giving people a chance to complain is a healthy outcome in and of itself. Letting that happen, if necessary, while having the side meeting be productive will take a good moderator and it won’t be me.

>On the other hand, there doesn't seem to be an active effort to include OpenSSL people in the meeting (as mentioned on the quicdev slack yesterday).

All it takes is for one person to forward my note to {omc,otc,openssl-committers} at openssl.org depending on which community you want to reach.  Or send them a link to the tweet from Nick https://twitter.com/gamernb/status/1455541263315439627 which points out that anyone can attend. I am sure they know of it. They certainly should know now because there’s one openssl.org address on the TLS list (and none on the QUIC list), although it’s certainly possible some folks on the project are using another mail provider. So maybe don’t forward things and bury them.

  *   Practical note for others: the time of the meeting seems to have changed yesterday, make sure you update your agendas (the timing in the trac seems correct/consistent with the changed ics).

Yes, the initial meeting didn’t account for the fact that the US switched from daylight time to standard time between now and then.  Sorry for the confusion.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 3 Nov 2021 13:53:51 +0000

Reposted here (with permission) since I think it's important to get this on
the record for discussion on this list.  It's always interesting to read about
protocol implementation details, especially if others can learn from them.

Peter.

-- Snip --

Please change your mind about your announced release plans
Salz, Rich rsalz at akamai.com
Fri Oct 29 15:13:35 UTC 2021

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/[email-masked]/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: Viktor Dukhovni <[email-masked]>
Date: Wed, 3 Nov 2021 12:30:10 -0400

> I'm wondering if you could give a bit more details about the expected

Indeed it is hard to see how OpenSSL project governance and development
priorities are a subject matter for the IETF TLS and/or QUIC working
groups.

-- 
    Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 3 Nov 2021 16:48:50 +0000

It's actually pretty easy to see.  Many IETF participants work for companies that depend on OpenSSL and the recent announcement has many concerned. Is there another open forum we can participate in?  Is there any way for the "voice of the people" to provide input?

When I was part of the project (which ended way back in 2018) we often lamented that we didn't have a good understanding of what the OpenSSL users were doing.  Well, this meeting might provide some of that missing feedback.