Re: [TLS] A side meeting on OpenSSL's plans about QUIC
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 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 :) > > > > [1] https://www.mail-archive.com/openssl-project@openssl.org/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 > > > > > > > > > -- 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A side meeting on OpenSSL's plans about QUIC
* 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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A side meeting on OpenSSL's plans about QUIC
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/openssl-project@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
Re: [TLS] A side meeting on OpenSSL's plans about QUIC
On Wed, Nov 03, 2021 at 11:12:00AM +0100, Robin MARX wrote: > I'm wondering if you could give a bit more details about the expected > outcome of this meeting? 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] A side meeting on OpenSSL's plans about QUIC
>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. 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. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Question regarding RFC 7366
Dear ladies and gentlemen, my question addresses the negotiation of the "encrypt_then_mac" extension proposed in RFC 7366 and, specifically, two possible interpretations of such negotiation when using AEAD ciphers. In summary, the client and server could interpret the negotiation of the extension differently during the handshake. Detailed description: In section 2 of RFC 7366, it states that "the client and server MUST NOT use encrypt-then-MAC unless both sides have successfully exchanged encrypt_then_mac extensions." This unambiguously implies that the encrypt_then_mac extension must not be used, if either the client or the server did not include the extension in their Hello messages during handshake. In this section, no restrictions is made whether encrypt_then_mac is to be used with only certain ciphersuites. However, in section 3, it is stated that "If a server receives an encrypt-then-MAC request extension from a client and then selects a stream or Authenticated Encryption with Associated Data (AEAD) ciphersuite, it MUST NOT send an encrypt-then-MAC response extension back to the client." Consequently, the correct/RFC-compliant behavior is unclear when the client and server wish to use mac_then_encrypt and an AEAD cipher such as AES_GCM. Two scenarios can exist as follows. 1. The client includes the encrypt_then_mac extension and AES_GCM as the ciphersuite in its Client Hello. The server responds and includes the encrypt_then_mac extension and AES_GCM in its Server Hello. Both sides have negotiated encrypt-then-MAC and apply it accordingly. This complies with section 2 but contradicts section 3 of the RFC. 2. The client includes the encrypt_then_mac extension and AES_GCM as the ciphersuite in its Client Hello. The server responds and does not include the encrypt_then_mac extension in its Server Hello. The chiphersuite remains to be AES_GCM. Following section 3, the server did not include the extension. However, based on section 2, this voids the usage of encrypt-then-MAC. For instance, the client may follow section 3 and apply encrypt_then_MAC, while the server does not as it follows section 2 of the RFC. I would really appreciate a response to get some clarification on what the intended interpretation is, i.e., when the extension should be used. Thank you and with best regards, Alexander Schlie ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Question regarding RFC 7366
On Tue, Nov 02, 2021 at 01:18:22PM +0100, alex.sch...@gmx.de wrote: > my question addresses the negotiation of the "encrypt_then_mac" extension > proposed in RFC 7366 and, specifically, two possible interpretations of such > negotiation when using AEAD ciphers. I think the source of the confusion is that AEAD ciphers are *neither* encrypt then MAC, nor MAC then encrypt (as two separate operations). They perform both as a single one-pass operation. The extension in question simply has no meaning with AEAD, and must not be sent by the server when an AEAD cipher selected, in which case the client and server just do AEAD. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Artart last call review of draft-ietf-tls-external-psk-guidance-03
Reviewer: Martin Thomson Review result: Ready with Issues This document addresses some of the less obvious aspects of how pre-shared keys can be used in TLS. A lot of this advice isn't specific to TLS, but it is a helpful document. For someone who might be deploying a protocol that relies on TLS - or might rely on it - the document is a useful resource. My only concern overall, and it is a vague concern, so I don't think action is needed, is that the document could probably use a little trimming. There are some parts of the document that are less useful than other parts. For example, the bit about who has the PSKs is great (one server, one client, don't swap roles); but it is repeated a little across multiple sections. The same applies to a few of the other points. It is probably not worth trying to edit the document down so that each point is made just once, because it isn't that bad, but a shorter document would be more impactful. A specific concern is the somewhat offhand way that early data is treated. The only mention is in a throwaway: "primarily for the purposes of supporting TLS connections with early data" buried in a bullet in Section 6. This is a pretty big topic and having absolutely no mention seems odd. I do think that it needs some treatment in the document. When early data is used with an external PSK, the only additional source of entropy that provides key diversity is the client's random value, which puts a lot of weight on that value containing sufficient entropy. In this case, even if the PSK is good enough, the entropy in the random is significant as it is what ensures traffic key diversity if the PSK is reused. Reusing a PSK for early data also likely leads to poor anti-replay performance if the random is not good enough. I have to apologize to the authors for missing this when it went through the working group. Fresh eyes and all that. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] tls@ietf112
Hey Sean, what is "Zero-Knowledge Proofs meet TLS"? I can't find a draft and the link in the agenda is busted. On Wed, Oct 20, 2021, at 06:46, Sean Turner wrote: > Hi! We have a meeting time scheduled for Tuesday, 9 November 2021 from > 1600-1800 (UTC). Please send in your agenda topics along with how much > time you think you will need to tls-cha...@ietf.org by 26 October 2021 > (early is better). > > Cheers > Chris, Joe, and Sean > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Question regarding RFC 7366
alex.sch...@gmx.de writes: >I would really appreciate a response to get some clarification on what the >intended interpretation is, i.e., when the extension should be used. There's not really any contradiction, encrypt-then-MAC has nothing to do with AEAD which is an all-in-one mode, so it doesn't apply to any AEAD cipher. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
