Re: OTC VOTE: Accept PR #16705 into 3.0
On Wed, Dec 08, 2021 at 09:17:05AM +0100, Tomas Mraz wrote: > On Tue, 2021-12-07 at 19:18 +0100, Kurt Roeckx wrote: > > On Tue, Dec 07, 2021 at 10:35:02AM +, Matt Caswell wrote: > > > topic: Accept PR #16705 into 3.0 subject to the normal review > > > process > > > > -1 > > > > From what I understand, this breaks our provider API. Providers > > that work with 3.0.0 will not work when that PR is applied, and > > providers that do the same implementation as that PR will not work > > with 3.0.0. That might be something that can be fixed in the PR. > > > > We might want to make changes like that, but we clearly need better > > rules for when it's acceptable to make such change, and how to make > > sure it's compatible. > > Kurt, can you please explain why do you think this breaks the provider > API compatibility with 3.0.0? I do not see any such breakage possible > from the PR. I was at least confused by: # define OSSL_KEYMGMT_SELECT_KEYPAIR\ ( OSSL_KEYMGMT_SELECT_PRIVATE_KEY | OSSL_KEYMGMT_SELECT_PUBLIC_KEY ) I assumed this was a different bit rather than the combination of 2 bits, and that we stopped calling it with the existing bit and called it with a new bit instead. But we're just calling it with an extra bit set. Kurt
Re: OTC VOTE: Accept PR #16705 into 3.0
On Tue, Dec 07, 2021 at 10:35:02AM +, Matt Caswell wrote: > topic: Accept PR #16705 into 3.0 subject to the normal review process -1 >From what I understand, this breaks our provider API. Providers that work with 3.0.0 will not work when that PR is applied, and providers that do the same implementation as that PR will not work with 3.0.0. That might be something that can be fixed in the PR. We might want to make changes like that, but we clearly need better rules for when it's acceptable to make such change, and how to make sure it's compatible. Kurt
2 factor authentication
Hi, The following vote passed with 6 in favour, 0 against, 0 abstain: topic: All committers to the main source repository must enable 2 factor authentication on GitHub Enterprise when it is moved there We plan to move all repositories from git.openssl.org to github.openssl.org which uses Github Enterprise. Note that this does not change where pull requests or issues should be made for the main source repository, only the place where the commits are pushed to will be changed. The repositories on github.com will stay a mirror like they are now. All committers will at some point in the future get an invite to create an account on github.openssl.org. Having write access to the main source repository will require that 2FA is enabled. Kurt
Re: OTC VOTE: Accept Policy change process proposal
On Mon, Nov 01, 2021 at 11:23:15AM +0100, Tomas Mraz wrote: > topic: Accept openssl/technical-policies PR#1 - the policy change > process proposal as of commit 3bccdf6. This will become an official OTC > policy. > > comment: This will implement the formal policy change process so we can > introduce and amend further policies as set by OTC via a public > process. +1 Kurt
Re: OTC VOTE: Accept PR#16725
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
Re: OTC VOTE: Accept PR#16725
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
Re: [External] : Agenda for the next OTC meeting
> 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
Re: Blog post about FIPS submission
On Thu, Sep 23, 2021 at 09:42:01PM +0200, Dmitry Belyavsky wrote: > Hello Matt, > > The link > https://csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-processmodules-in-process-list > (You can see the official listing for the submission *here*) seems to be > not working It seems to be: https://csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-process/modules-in-process-list (A missing /, the URL is also case insensitive.) Kurt
Re: OTC vote: include Keccak digests in OpenSSL
On Tue, Sep 21, 2021 at 06:37:42PM +0200, Tomas Mraz wrote: > On Tue, 2021-09-21 at 18:32 +0200, Kurt Roeckx wrote: > > On Tue, Sep 21, 2021 at 07:14:51PM +1000, Dr Paul Dale wrote: > > > Accept PR#16594 into master subject to the normal review process > > > > > > > > > > > > This doesn't meet the "is a standard" requirement but it is in use > > > and we > > > have the implementation. It just isn't exposed. > > > > Can you describe where it is in use? > > > > Citation from the issue #13033 linked from the PR: > > "Ethereum and after it many cryptographic applications use the original > pre-NIST variant of SHA3-256, these days named keccak256, where the > delimiter byte is 0x1 rather than 0x6." +1 Kurt
Re: OTC VOTE: Increase the default security level from 1 to 2
On Tue, Sep 21, 2021 at 11:08:40AM +0100, Matt Caswell wrote: > topic: Increase the default security level from 1 to 2 in master +1 Kurt
Re: OTC vote: include Keccak digests in OpenSSL
On Tue, Sep 21, 2021 at 07:14:51PM +1000, Dr Paul Dale wrote: > Accept PR#16594 into master subject to the normal review process > > > > This doesn't meet the "is a standard" requirement but it is in use and we > have the implementation. It just isn't exposed. Can you describe where it is in use? Kurt
Re: OTC VOTE: Restart merging of non-breaking small features
On Tue, Sep 14, 2021 at 11:13:13AM +0100, Matt Caswell wrote: > topic: Allow the restart of merging of non-breaking small features to the > master >branch +1 Kurt
Re: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]
I currently fail to see why you can't describe in words what you intend to fix. The PR itself has a subject, so have the commits. One of the reasons we have this vote is public is so that people reading this list can comment on it. Just some number doesn't tell them anything without having to go and look it up and spend time trying to understand. A simple summary of what we intend to vote on will help them understand if they want to look at this or not. If you feel that it should not be part of the vote text, can we at least have some introduction text? For instance PR 16203 was about adding the TLS 1.3 KDF. I can see several vote text for that: - Add the TLS 1.3 KDF to the provider in 3.0. - Add the TLS 1.3 KDF to the provider, and use it in the ssl library in 3.0 so that TLS 1.3 can be used in FIPS mode. - Add support for using TLS 1.3 in FIPS mode in 3.0 Most of our votes are not about how it's implemented, but really a general direction. As you say yourself, it's about proceeding in that direction. I don't see why you can't describe that direction with words. Some of the PR and issues we vote on have different view points based on the comments. Am I voting on the last comment made in the PR or issue? With a PR you can argue it's not the comments but the code, but what happens in case the PR is changed before I can vote? We have also voted on issue, were several things were mentioned in the issue, some things I agree we should do, others I don't. Kurt On Wed, Aug 04, 2021 at 08:25:59AM +1000, Tim Hudson wrote: > The votes on the PR are precisely that - to vote to proceed with the PR via > the normal review process - and that means looking at the varying > viewpoints. > If we reached a consensus that overall we didn't think the PR made sense > then we wouldn't form a vote of that form. > > What you are voting for is that what the PR holds is what makes sense to > proceed with - subject to the normal review process - i.e. this isn't a > push-the-PR-in-right-now vote - it is a "proceed" vote. > > A PR has a discussion in the PR comments, and generally an associated > issue, and always (as it is a PR) the suggested code change. > That is what is being voted on - to proceed with the PR - via the normal > review process. > > As otherwise the PR remains blocked on an OTC decision - and the OTC > decision is to not continue to block the PR (blocked on an OTC decision). > > Repeating again - the PR itself is what is being voted about - not a set of > different unstated viewpoints - it is what is in the PR - fix this problem > - and generally there is nothing critical seen in the code approach - but > our normal review processes still apply to handle it. Which means the PR > simply needs the two approvals. > > The majority of the time in the OTC discussions we are actually looking at > the PR details in terms of the code changes - we aren't reviewing it as > such (although that does sometimes happen on the call) - we are looking at > the PR code changes providing the additional detail to help in the decision > making. > > There are very few PRs which describe what is going to change in a useful > form independent of the code changes - they don't usually state things like > what is going to be changed - they are focused on what is wrong and the PR > is going to fix it - there isn't usually anything meaningful about what is > going to be changed in order to fix what is wrong. > > A PR doesn't hold a range of code fixes to choose between - it holds a > discussion (comments) and a specific code fix - and perhaps that specific > code fix is the result of a sequence of code fixes that have evolved > through the discussion. > > So the precise viewpoint you are voting for in those PRs is to proceed to > include that PR in the work for the current release while continuing to use > our normal review and approval processes - that is the vote text - and it > makes the intent of the vote. > > Where there is a view that we should not take a particular approach > represented in a PR and should take an alternate approach then we don't > form a vote that way - we actually allocate someone to produce an alternate > PR. Often we leave the initial PR and alternate PR open until such time as > we can compare the approaches in concrete form and then we can make a > decision - but that would be accepting one PR over another PR. We have had > "competing" PRs regularly - and we then vote on the alternatives - where it > is clear what the alternatives are. A single PR vote is about that PR. > On Wed, Aug 4, 2021 at 8:07 AM Kurt Roeckx wrote: > > > On Wed, Aug 04, 2021 at 07:21:57AM +1000, Tim Hudson wrote: > > > > > > This isn't about the OTC meeting itself - this is about the details of > > the
Re: OTC VOTE: Accept PR#16286 into 3.0 subject to the normal review process
On Tue, Aug 17, 2021 at 02:19:08PM +0100, Matt Caswell wrote: > topic: Accept PR#16286 into 3.0 subject to the normal review process -1 Do we need some general policy for such changes after the 3.0 release? Kurt
Re: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1
On Wed, Aug 11, 2021 at 09:53:14PM +0300, Nicola Tuveri wrote: > On the other hand, 1.1.1 is not in its last year of support so it is not > limited to security fixes only. > > The commits which this vote proposes to revert fixed a bug that produced > invalid output from functions with a clear intent. > This might have security repercussions, as the user might end up signing > something which is unexpectedly invalid. > But even without concrete security vulnerabilities on record, if we > classify invalid output as a bug this should be fixed in 1.1.1. > > There are applications that might be broken, because they relied on the > buggy behavior for producing invalid output as intermediate data, but, as > mentioned in #16266, there are ways of producing the required non-x509 data > without abusing functions meant to produce valid x509. > > It is unfortunate for existing applications to break upon a patch release, > but given that patch releases for 1.1.1 are meant to fix security defects > and bugs, this is inevitable for any application relying on buggy behavior > (especially as in the case that triggered this discussion, which configures > a clear abuse of the API, while alternative non-abusive ways of achieving > the intended result exist). There are a lot of things we accept in a certificate we shouldn't. And I would like to fix all of them. But fixing them in stable branches is going to cause people problems and prevent them from upgrading to a newer version and getting other security fixes. I prefer to only do breaking changes in a minor version. Kurt
Re: OTC VOTE: Revert the commits merged from PR #16027 in 1.1.1
On Tue, Aug 10, 2021 at 11:53:23AM +0100, Matt Caswell wrote: > topic: Revert the commits merged from PR #16027 in 1.1.1 +1 Kurt
Re: OTC quick votes [WAS: RE: OTC vote PR #16171: config_diagnostic]
On Wed, Aug 04, 2021 at 07:21:57AM +1000, Tim Hudson wrote: > > This isn't about the OTC meeting itself - this is about the details of the > topic actually being captured within the PR. > You need to actually look at the PR to form a view. And we do add to the > PRs during the discussion if things come up and we review the PR details. > So the vote isn't about an OTC discussion - the vote is precisely about the > PR itself. > > One of the things we have explicitly discussed on multiple calls is that in > order to be informed of the details, you need to consult the PR which has a > record of the discussion and often viewpoints that offer rather different > positions on a topic - and those viewpoints are what should be being > considered. I am happy to read the issue/PR to see the different view points. But different viewpoints is exactly the problem, which of those am I voting for? During a meeting, there probably was a consensus about what you're actually voting for, but that information is lost. In general, I want a vote to be about what is going to change, the how isn't important most of the time. Kurt
Re: OTC VOTE: Approve the release of 3.0 beta 2
On Tue, Jul 27, 2021 at 10:11:53AM +0100, Matt Caswell wrote: > topic: OTC approve the release of 3.0 beta2 on Thursday 29th July +1 Kurt
Re: OTC VOTE: Accept PR 16050 in 3.0
On Tue, Jul 27, 2021 at 10:10:27AM +0100, Matt Caswell wrote: > topic: Accept PR 16050 in 3.0 subject to our normal review process > Proposed by Tim Hudson > Public: yes > opened: 2021-07-20 > closed: 2021-07-27 > accepted: no (for: 1, against: 3, abstained: 4, not voted: 1) I don't find a call for vote on this. -1 Kurt
Re: OTC VOTE: Accept PR 16128
On Thu, Jul 22, 2021 at 01:51:27PM +0100, Matt Caswell wrote: > topic: Accept PR 16128 in 3.0 subject to our normal review process +1 Kurt
Re: OTC Vote: Accept PR #16118
On Tue, Jul 20, 2021 at 11:18:27AM +0100, Matt Caswell wrote: > topic: We should accept PR #16118 into 3.0 when completed and subject to the >normal review process This already seems to be merged, so I'll vote 0. Kurt
Re: OTC VOTE: Fix issue #16088
> topic: We should fix the issue described in #16088 for 3.0 After reading #16088, I have no idea what this vote means, so I will vote -1. Please stop referring to a github issue or pull request as vote text and actually describe what we're voting on. Since this describes a regression against 1.1.1, and fixing it, I don't actually see a need to vote on this. Not fixing it would require a vote. Kurt
Re: OTC VOTE: Allow the addition of EVP_PKEY_get0_provider() and EVP_PKEY_CTX_get0_provider()
On Tue, Jul 13, 2021 at 11:24:55AM +0100, Matt Caswell wrote: > topic: Allow the addition of EVP_PKEY_get0_provider() and >EVP_PKEY_CTX_get0_provider() calls in 3.0 -1 Kurt
Re: OTC VOTE: Remove ERR_GET_FUNC in 3.0
On Tue, Jul 06, 2021 at 10:26:13AM +0100, Matt Caswell wrote: > topic: Remove ERR_GET_FUNC in 3.0 > Proposed by Nicola Tuveri > Public: yes > opened: 2021-07-06 > closed: 2021-07-06 > accepted: yes (for: 6, against: 1, abstained: 0, not voted: 2) There seem to be no good solutions here, so I'm voting 0. Kurt
Re: OTC VOTE: Accept PR #15763
On Tue, Jun 29, 2021 at 10:50:36AM +0100, Matt Caswell wrote: > topic: Accept PR #15763 for 1.1.1 subject to the normal review process +1 Kurt
Re: VOTE: 3.0 beta1 readiness
On Tue, Jun 15, 2021 at 10:53:03AM +0100, Matt Caswell wrote: > topic: OTC approve the release of 3.0 beta1 on Thursday 17th June on the > basis >that: 1) all current approved PRs with the beta1 milestone are merged >2) issues #15755 and #15756 are resolved 3) We accept that VMS does > not >currently pass tests but expect it to do so before 3.0 final (issue >#15757) 0 Kurt
Re: OTC VOTE: Reject PR#14759
On Tue, Apr 20, 2021 at 01:23:56PM +0300, Nicola Tuveri wrote: > Following up on > https://www.mail-archive.com/openssl-project@openssl.org/msg02407.html we > had a discussion on this during last week OTC meeting, and opened a vote > limited exclusively to the matter of rejecting PR#14759. > > We lost the record of the votes collected during the call, so opening it > officially today with a clean slate. > > > > topic: Reject PR#14759 +1 Kurt
Re: OTC VOTE: Set PR 13817 milestone to Post 3.0
On Tue, Apr 20, 2021 at 12:17:17PM +0200, Tomas Mraz wrote: > topic: Set PR 13817 milestone to Post 3.0 0 Kurt
Re: OTC VOTE: Set issue 11164 milestone to Post 3.0
On Tue, Apr 20, 2021 at 12:15:19PM +0200, Tomas Mraz wrote: > topic: Set issue 11164 milestone to Post 3.0 > Proposed by Tim Hudson > Public: yes > opened: 2021-04-20 > closed: 2021-04-20 > accepted: yes (for: 6, against: 1, abstained: 0, not voted: 4) -1 Kurt
OTC VOTE: EVP_PKEY types are immutable once set
Hi, I just found this in votes.txt, it looks like it was not mailed to the list as required. topic: EVP_PKEY types are immutable once set. Types cannot be changed once set. To move from one type to another compatible type will require export/import. Comment: This will result in breaking changes compared to previous releases. Proposed by Tim Public: yes opened: 2021-03-23 closed: 2021-03-23 accepted: yes (for: 6, against: 0, abstained: 0, not voted: 5) Matt [+1] Mark [ ] Pauli [+1] Viktor [ ] Tim[+1] Richard[+1] Shane [+1] Tomas [+1] Kurt [ ] Matthias [+1] # 2021-03-23 Nicola [+1] # 2021-03-30 I'm voting +1 on this. Kurt
Re: OTC VOTE: Add a description field to OSSL_ALGORITHM
On Tue, Mar 23, 2021 at 09:12:40AM +, Matt Caswell wrote: > This vote has now closed: > > accepted: yes (for: 5, against: 1, abstained: 1, not voted: 4) It seems unclear to me that you can close the vote at this time. The result is not clear, the 4 people who didn't vote can vote -1 in which case it doesn't pass. The vote period is between 7 and 14 days, but no close date was specified as required by the bylaws. I think we normally use 14 days. Anyway, voting -1. Kurt > On 16/03/2021 10:10, Matt Caswell wrote: > > topic: Add a description field to the OSSL_ALGORITHM structure > > Comment: See Issue #14514 for background > > Proposed by Matt Caswell > > Public: yes > > opened: 2021-03-16 > > closed: 2021-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > > > Matt [+1] > > Mark [ ] > > Pauli [-1] > > Viktor [ ] > > Tim [ ] > > Richard [+1] > > Shane [ 0] > > Tomas [+1] > > Kurt [ ] > > Matthias [ ] > > Nicola [+1]
Re: OTC VOTE: Disallow SM2 with a non-SM2 curve
On Tue, Mar 09, 2021 at 10:24:32AM +, Matt Caswell wrote: > topic: In 3.0 it will not be possible to use SM2 with a non-SM2 curve. This >should be documented. +1 Kurt
Re: OTC VOTE: Disallow SM2 with a non-SM2 curve
On Wed, Mar 10, 2021 at 05:44:22AM +0200, Nicola Tuveri wrote: > Yes, in 1.1.1j the following is possible: > > - SM2 cryptosystem operations over the "SM2 curve" > - SM2 cryptosystem operations over arbitrary curve (including NIST ones) > - ECDSA/ECDH cryptosystem operations over the "SM2 curve" Is there any reason why we want to support the last 2? > In 3.0, we want to get rid of `EVP_PKEY_set_alias_type()` and make the > "type" of a key object immutable: this will be a breaking change for > applications that were using SM2 in 1.1.1. I assume that's because they got the wrong type when reading a file with that, but it's unclear to me what they should do instead. What I see is: - We'll change the parser so it sets the correct type and there is no need to change the type - Your proposal where you need to export it, and import it again using a different type, making it very complicated to work with SM2. Kurt
Re: OTC VOTE: Disallow SM2 with a non-SM2 curve
On Tue, Mar 09, 2021 at 03:57:32PM +0200, Nicola Tuveri wrote: > It is tangent to the vote in itself, but I'd like to highlight that in part > this vote is motivated by getting rid of cases where there is a need to > convert between compatible key types (e.g. SM2 & EC, DH & DHX). > > The vote of this text does not cover it, but another use case that we will > likely lose in 3.0 when this vote passes is using ECDH/ECDSA over the curve > identified by the SM2 OID. > > It's likely another niche use, not relevant for any production system, but > it is creating a precedent where OpenSSL accepts that the SM2 standard > overrides the SECG standard. > > In 1.1.1 we do _default_ to decode a key serialized as "SECG EC over the > SM2 OID curve" as a SM2 key, but we are not preventing developers from > creating an EC key object over that curve, nor an SM2 key object over any > other curve (serialization of such "weird" key objects would be identical, > deserialization would require an explicit set_alias call to mutate from the > default type). > > With the changes proposed as a corollary to this vote that were discussed > on the last OTC meeting, we would remove this ability: we could maybe still > create an ephemeral "EC over SM2 OID" key object but there would be no way > to deserialize one. > > > I would instead prefer to vote on requiring for 3.0 a mechanism to > "convert" key types: an EVP_PKEY_todata function to mirror > EVP_PKEY_fromdata. > It will be then up to the individual keymgmt of the source key object to > decide if it can be exported to OSSL_PARAMs, and to the receiving keymgmt > on which fromdata is called to determine if the input OSSL_PARAMs are valid > to create a proper key object. > Yes, we would still have a breaking change (set_alias needs to be replaced > by the todata/fromdata dance) but we wouldn't lose functionality. > > Such a mechanism could be useful also beyond the current problem of key > conversions within the builtin providers, and allow future proofing and > interoperability between different providers that might end up using > different names for compatible key types (for whatever reason it might > happen). This text does not seem to help me to make a vote, it seems I just get more questions. The EVP_PKEY_set_alias_type() manpage says that SM2 use the same encoding an ECDSA. I assume that during deserialization we don't know if we should create an ECDSA key or an SM2 key, because we don't look at the OID when deserializing and always create an ECDSA key. My understanding is that there is code that needs to know an SM2 key is stored in that object, and is not looking at the OID, but instead looks at what the pkey type is. My suggested fix for that would be to make the deserialization smarter so it sets the correct pkey type base on the OID. Assuming that we can get an SM2 key, I currently fail to see why ECDSA or ECDH wouldn't work with them, but I know very little about SM2. I also don't understand what the vote is really about. Can 1.1.1 do SM2 on one of the nist curves? Kurt
Re: OTC VOTE: EVP init functions and the provider interface
On Tue, Mar 09, 2021 at 10:25:50AM +, Matt Caswell wrote: > topic: EVP init functions take an OSSL_PARAM array to set parameters and > this >should be reflected in the equivalent provider interface. +1 Kurt
Re: OTC VOTE: EVP init functions and the provider interface
On Tue, Mar 09, 2021 at 10:25:50AM +, Matt Caswell wrote: > topic: EVP init functions take an OSSL_PARAM array to set parameters and > this >should be reflected in the equivalent provider interface. I need more information than the vote text to be able to vote on this. Kurt
Re: OTC VOTE: Change behaviour of EVP_PKEY_get0/EVP_PKEY_get1 functions
On Tue, Mar 02, 2021 at 10:20:30AM +, Matt Caswell wrote: > topic: EVP_PKEY_get0 functions will return a cached copy of the legacy key, > and > will be changed to return const. EVP_PKEY_get1 functions work as per > EVP_PKEY_get0 but are not const returns and up the reference count > Comment: See PR #14319 for background > Proposed by Matt Caswell > Public: yes > opened: 2021-03-02 > closed: 2021-02-02 It closed before it was opened. I'm voting 0. Kurt
Re: OTC Vote: Remove the RSA_SSLV23_PADDING and related functions completely
On Tue, Feb 23, 2021 at 11:21:41AM +0100, Tomas Mraz wrote: > topic: The RSA_SSLV23_PADDING and related functions should be > completely removed from OpenSSL 3.0 code. +1 Kurt
Re: OSSL_PARAM behaviour for unknown keys
On Tue, Dec 15, 2020 at 08:45:45AM +0100, Richard Levitte wrote: > Whatever we decide on this, I would rather not burden provider authors > with having to check for all sorts of things they aren't interested in. I think you write the provider just a little bit different than what you might be doing now. > I've often had the fictitious algorithm BLARGH (someone should invent > it, just 'cause), and while everyone with access to specs could write > a provider, some might extend it as well, with extra parameters (like > the CRT params for RSA keys) or flags or whatnot. If we burden the > providers with the sort of checks that are discussed here, it would > require every BLARGH implementation to be constantly in sync with > every other BLARGH implementation. That's not a very good idea (*) So you're saying that the applications should change depending on which provider it has loaded? One implementation can name the parameter for the same functionality different than the other? I guess it's then up to the application to query which provider is loaded, and see which parameter it should set for that provider? But it's unlikely that all applications will properly check that the provider provides all the functionality it needs. And we should do what we can to prevents problems. > So, I'm thinking that control should remain with the application / > libcrypto. However, I'll also maintain that, as a matter of protocol, > we can ask the providers to set the return_size field for any > parameter they use, as a way to help out. That would enable the use > of functions like OSSL_PARAM_modified() on the application / libcrypto > side when setting parameters, just at it currently does for getting > them. From a provider author point of view, I'd say that's a much > lesser burden than having to have knowledge of all sorts of params any > other provider might support. To get back to the RSA / CRT example. If you write a provider to do RSA but don't use the CRT parameters, and the application loads the provided key with CRT parameters, it's not hard for a provider to know some other provider might use the CRT parameters and so can ignore it. But it's also fine that it returns an error at first, the application will either switch to an other provider, or the provider will get fixed to ignore it. If it's for a parameter that enables a new mode, and the mode is not supported by the provider, we need a way to check that that mode is supported. For intance blake2 has an optional key, but we never implemented it because the API didn't support setting it. If at some point it is added, an application needs to have a way to make sure it supported. The options I see are: 1) The fetch function should support requesting a version that has support for it. 2) You fetch something and: a) You set the parameter, and check for an error. b) You ask the settable parameters and check that it supports it. It's my understand that you can't get all the parameters in some cases, so this isn't always possible. I don't actually see many applications do 2b), they'll do 2a) and currently don't get an error. It's also likely they will not do 1) correctly, because it was written against a provider that did support it, so it was not clear they needed to request that feature, and so again will currently not get an error, and will be hard to debug. We can detect that the application is trying to do something that's not going to work and should return an error in that case. We need 1), but the question is how fine grained we want to do that, or what we expect a provider to implement asking for a feature. For intance, if we want to load a multiprime RSA key, not all providers will support that, and as far as I know, the FIPS provider will not support that. Note all providers will even support loading an RSA private key, so when fetch RSA, we really need to say that we should be able to set the key. We need documentation that says what you can expect to do depending on the features you requested. As far as I know, if you currently try to load a multiprime key into the FIPS provider, it will not give you any error, it will just not do what you want it to do. We need to define how we're going to deal with all this. I prefer that it's in some consistent way. Kurt
Re: OSSL_PARAM behaviour for unknown keys
On Tue, Dec 15, 2020 at 08:40:03AM +0100, Dmitry Belyavsky wrote: > > There are 2 variants of using OpenSSL. > 1. Algorithm-agnostic. We can deal with most of the algorithms in a more or > less similar way. > That was the way we dealt with various algorithms in libcrypto since 1.0 > version. > > 2. Algorithm-specific. The API user should take into account which > algorithms are > supported by their application and provide some specific processing. > > These are two different approaches. I'm not really sure what you're trying to say. 1) seem to be things like EVP_CIPHER, EVP_MAC, and so on, while 2) seems to be RSA, ECDSA, AES APIs. And 2) is then something we want to get rid of. What we want is that the interface to the algorithm doesn't depend on the algorithm. But even in the same type of algorithmd, some might need more parameters, support different modes, and things like that, so we need a way set all those options. We now have an OSSL_PARAM that can make this much more flexible, and we don't need to add a new function/macro each time we want to do something new. If an applications wants to switch from one to the other algorithm, it should be as easy as possible. But the application might need to change, and might need to be aware which parameters are needed. If the application passes the RSA parameters itself to OpenSSL and it wants to switch to EdDSA, it will not continue to pass the primes, exponent, and so on. I think if it did try that, we should return an error. Kurt
Re: OSSL_PARAM behaviour for unknown keys
On Mon, Dec 14, 2020 at 08:20:29PM +0100, Dmitry Belyavsky wrote: > Dear Kurt, > > > On Mon, Dec 14, 2020 at 3:59 PM Kurt Roeckx wrote: > > > Hi, > > > > doc/man3/OSSL_PARAM.pod current says: > > Keys that a I or I doesn't recognise should > > simply be ignored. That in itself isn't an error. > > > > The intention of that seems to be that you just pass all the data > > you have, and that it takes data it needs. So you can pass it data > > that it doesn't need because it's only used in case some other parameter > > has some specific value. For example, depending on the DRBG mode > > (HMAC, CTR, HASH) you have different parameters, and you can just > > pass all the parameters for all the modes. > > > > I think for behaviour for a setter is not something that we want, > > it makes it complicated for applications to check that it will > > behave properly. I think that in general, if the applications > > wants to set something and you don't understand it, you should > > return an error. This is about future proofing the API. For > > instance, a new version supports a new mode to work in and that > > needs a new parameter. If it's build against a version that knows > > about it, but then runs against a version that doesn't know about > > it, everything will appear to work, but be broken. If we return > > an error, it will be clear that it's not supported. > > > > An alternative method of working is that the application first > > needs to query that it's supported. And only if it's supported > > it should call the function. But we don't have an API to query for > > that. You might be able to ask for which keys you can set, but it > > doesn't cover which values you can set. I hope we at least return > > an error for a known key with an unknown value. But it's my > > understanding that we currently don't always return all supported > > keys, and that the supported keys can depend on one of the set > > parameters. > > > > I suggest that we change the return value to indicate that all > > parameters have been used or not. For instance return 1 in case > > all used, return 2 in case not all used. > > > > > From my GOST implementor's experience, the provider can get a lot of > parameters. > Some of them are supported, some of them are not. > > The particular provider is the only subsystem that knows which parameters > are supported and which are necessary for the operations. > > So the caller can provide some unsupported parameters, some supported and > some totally wrong for the provider. > These are the cases that must be distinguishable on the caller side. If I understand you correctly, what you're saying is that it's sometimes ok to ignore some parameters. For instance, if you try to create an RSA object, and you pass it CRT parameters, and the implementation doesn't do anything with them, it can ignore them if it wants to. I would say that the provider should know what those parameters mean, so that it's not an "unknown key", it just ignores them, at which points it can say that it understands all the parameters. Some might argue that they don't want to use something that doesn't make use of the CRT parameters, but then they probably shouldn't be using that provider to begin with. > After that the provided EVP object should be either in a consistent state > or not, assuming the upcoming operation. The object should always be in a consistent state. I would prefer that in case of failure the object is not created (or modified). Which brings us to some other open points about the API we have. We should not introduce new APIs where you can modify the state of the object, so it can not be in a non-consistent state. It's much more simple to get things correct in that case. But as long as we have to support old APIs where it can be modified, the prefered consistent state is to not mofify the object on error. Some APIs make this very hard, so the other acceptable state is that you can free the object. With an API that doesn't allow modification, either you get a complete object, or you get no object. Kurt
OSSL_PARAM behaviour for unknown keys
Hi, doc/man3/OSSL_PARAM.pod current says: Keys that a I or I doesn't recognise should simply be ignored. That in itself isn't an error. The intention of that seems to be that you just pass all the data you have, and that it takes data it needs. So you can pass it data that it doesn't need because it's only used in case some other parameter has some specific value. For example, depending on the DRBG mode (HMAC, CTR, HASH) you have different parameters, and you can just pass all the parameters for all the modes. I think for behaviour for a setter is not something that we want, it makes it complicated for applications to check that it will behave properly. I think that in general, if the applications wants to set something and you don't understand it, you should return an error. This is about future proofing the API. For instance, a new version supports a new mode to work in and that needs a new parameter. If it's build against a version that knows about it, but then runs against a version that doesn't know about it, everything will appear to work, but be broken. If we return an error, it will be clear that it's not supported. An alternative method of working is that the application first needs to query that it's supported. And only if it's supported it should call the function. But we don't have an API to query for that. You might be able to ask for which keys you can set, but it doesn't cover which values you can set. I hope we at least return an error for a known key with an unknown value. But it's my understanding that we currently don't always return all supported keys, and that the supported keys can depend on one of the set parameters. I suggest that we change the return value to indicate that all parameters have been used or not. For instance return 1 in case all used, return 2 in case not all used. Kurt
Re: OTC VOTE: Keeping API compatibility with missing public key
On Fri, Dec 04, 2020 at 01:45:07PM +0100, Tomas Mraz wrote: > topic: For 3.0 EVP_PKEY keys all algorithm implementations that were usable >with 1.1.1 EVP_PKEY API or low level APIs without public component must >stay usable. > >This overrules the > * all implementations apart from EC require the public component to > be present; >part of the vote closed on 2020-11-17. > +1 Kurt
Re: OTC VOTE: Fixing missing failure exit status is a bug fix
On Mon, Nov 30, 2020 at 02:03:15PM +0200, Nicola Tuveri wrote: > Vote text > - > > topic: In the context of the OpenSSL apps, the OTC qualifies as bug >fixes the changes to return a failure exit status when a called >function fails with an unhandled return value. >Even when these bug fixes change the apps behavior triggering >early exits (compared to previous versions of the apps), as bug >fixes, they do not qualify as behavior changes that require an >explicit OMC approval. +1 Kurt
Re: [OMC VOTE PROPOSAL] macOS ARM64 Support in OpenSSL 1.1.1 LTS
On Fri, Nov 27, 2020 at 12:42:44PM +0100, Felix Bünemann wrote: > Hi Kurt, > > > Am 26.11.2020 um 18:57 schrieb Kurt Roeckx : > > > > On Wed, Nov 25, 2020 at 09:17:13PM +0100, Felix Bünemann wrote: > >> > >> It is also unique cause it requires no code changes to support a new > >> platform. > > > > In a previous discussion we have talked about when a platform can > > be added in an LTS release. I think that in general if it's only > > configuration changes and there is a very low risk that it's going > > to have issues requiring other changes, we should allow it. > > Do you have a link to that discussion? It was in one of our online meetings, that resulted in the LTS+ proposal. > If there is a prior example where this has happened I should also remove the > statement that it is a unique case and mention the prior incident instead. As far as I know, there are no examples where we have allowed adding a platform in the stable release branch. Kurt
Re: [OMC VOTE PROPOSAL] macOS ARM64 Support in OpenSSL 1.1.1 LTS
On Wed, Nov 25, 2020 at 09:17:13PM +0100, Felix Bünemann wrote: > > It is also unique cause it requires no code changes to support a new platform. In a previous discussion we have talked about when a platform can be added in an LTS release. I think that in general if it's only configuration changes and there is a very low risk that it's going to have issues requiring other changes, we should allow it. Kurt
Re: [OTC VOTE PROPOSAL] Fixing missing failure exit status is a bug fix
On Tue, Nov 24, 2020 at 01:51:44PM +0200, Nicola Tuveri wrote: > Background > -- > > This follows up on a [previous proposal] that was abandoned in favor of > an OMC vote on the behavior change introduced in [PR#13359]. > Within today's OTC meeting this was further discussed with the attending > members that also sit in the OMC. > > The suggestion was to improve the separation of the OTC and OMC domains > here, by having a more generic OTC vote to qualify as bug fixes the > changes to let any OpenSSL app return an (early) failure exit status > when a called function fails. > > The idea is that, if we agree on this technical definition, then no OMC > vote to allow a behavior change in the apps would be required in > general, unless, on a case-by-case basis, the "OMC hold" process is > invoked for whatever reason on the specific bug fix, triggering the > usual OMC decision process. > > Proposed vote text > -- > > In the context of the OpenSSL apps, we qualify as bug fixes the > changes to return a failure exit status when a called function > fails unrecoverably. I'm not sure the unrecoverably should be there. I think this was about verifying is a public or private key was valid. If such a function returns it's not valid, I don't call that an unrecoverable error. But I do expect the application to return an error exit code. An other example is s_client, which ignores verification errors by default. You can change that behaviour with -verify_return_error. If you do that, s_client will actually exit with return value 1 in case of a verification error. Kurt
Re: OTC VOTE: EVP_PKEY private/public key components
On Tue, Nov 03, 2020 at 12:11:27PM +, Matt Caswell wrote: > > The proposal discussed was that while relaxing the conceptual model, > most of the existing implementations would still require both. The EC > implementation would be relaxed however. This essentially gives largely > compatible behaviour between 1.1.1 and 3.0. > > The vote text is as follows: > > topic: For 3.0 EVP_PKEY keys, the OTC accepts the following resolution: > * relax the conceptual model to allow private keys to exist without public > components; > * all implementations apart from EC require the public component to be > present; > * relax implementation for EC key management to allow private keys that > do not > contain public keys and > * our decoders unconditionally generate the public key (where possible). > > Proposed by Matt Caswell > Public: yes > opened: 2020-11-03 > closed: 2020-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) So I think being compatible with what 1.1.1 does is important. And what the text does is try to make rules for what 1.1.1 does, but as far as I understand it, it's not really describing what 1.1.1 does. I think we should just fix the regressions. For fixing the regressions we don't need a vote. You can argue that that would violate some rule or model that some people think we have, but clearly we didn't have it. So I'm voting -1. Kurt
Meaning of no-xxx option
Hi, It seems that we might start to interprete the no-xxx options differently. In 1.1.1 it would completly disable the feature in libcrypto, the apps and libssl. It seems that now the interpretation changed to just disable the support for it in the provider. You might load a different provider that does support it, and so the apps and libssl can use it then. My interpretation was always that we want to completly disable the feature, for instance because we don't want to use it at all or we want to reduce the size of the binries. Kurt
Re: OTC VOTE: The PR #11359 (Allow to continue with further checks on UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch
On Fri, Oct 09, 2020 at 02:02:29PM +0200, Tomas Mraz wrote: > topic: The PR #11359 (Allow to continue with further checks on > UNABLE_TO_VERIFY_LEAF_SIGNATURE) is acceptable for 1.1.1 branch > As the change is borderline on bug fix/behaviour change OTC needs > to decide whether it is acceptable for 1.1.1 branch. > Proposed by Tomas Mraz > Public: yes > opened: 2020-10-09 > closed: 2020-mm-dd 0 Kurt
Re: VOTE: Technical Items still to be done
On Thu, Oct 08, 2020 at 03:47:18PM +0100, Matt Caswell wrote: > topic: The following items are required prerequisites for the first beta > release: > 1) EVP is the recommended API, it must be feature-complete compared with > the functionality available using lower-level APIs. >- Anything that isn’t available must be put to an OTC vote to exclude. >- The apps are the minimum bar for this, subject to exceptions noted > below. > 2) Deprecation List Proposal: DH_, DSA_, ECDH_, ECDSA_, EC_KEY_, RSA_, > RAND_METHOD_. >- Does not include macros defining useful constants (e.g. > SHA512_DIGEST_LENGTH). >- Excluded from Deprecation: `EC_`, `DSA_SIG_`, `ECDSA_SIG_`. >- There might be some others. >- Review for exceptions. >- The apps are the minimum bar to measure feature completeness for > the EVP > interface: rewrite them so they do not use internal nor deprecated > functions (except speed, engine, list, passwd -crypt and the code > to handle > the -engine CLI option). That is, remove the suppression of deprecated > define. > - Proposal: drop passwd -crypt (OMC vote required) >- Compile and link 1.1.1 command line app against the master headers and > library. Run 1.1.1 app test cases against the chimera. Treat this > as an > external test using a special 1.1.1 branch. Deprecated functions > used by > libssl should be moved to independent file(s), to limit the > suppression of > deprecated defines to the absolute minimum scope. > 3) Draft documentation (contents but not pretty) >- Need a list of things we know are not present - including things we > have > removed. >- We need to have mapping tables for various d2i/i2d functions. >- We need to have a mapping table from “old names” for things into the > OSSL_PARAMS names. > - Documentation addition to old APIs to refer to new ones (man7). > - Documentation needs to reference name mapping. > - All the legacy interfaces need to have their documentation > pointing to >the replacement interfaces. > 4) Review (and maybe clean up) legacy bridge code. > 5) Review TODO(3.0) items #12224. > 6) Source checksum script. > 7) Review of functions previously named _with_libctx. > 8) Encoder fixes (PKCS#8, PKCS#1, etc). > 9) Encoder DER to PEM refactor. > 10) Builds and passes tests on all primary, secondary and FIPS platforms. > 11) Query provider parameters (name, version, ...) from the command line. > 12) Setup buildbot infrastructure and associated instructions. > 13) Complete make fipsinstall. > 14) More specific decoding selection (e.g. params or keys). > 15) Example code covering replacements for deprecated APIs. > 16) Drop C code output options from the apps (OMC approval required). > 17) Address issues and PRs in the 3.0beta1 milestone. > Proposed by . > Public: yes > opened: 2020-10-08 -1 I think we can delay some of that work until 3.1. Kurt
Re: VOTE: Weekly OTC meetings until 3.0 beta1 is released
On Fri, Oct 09, 2020 at 03:00:00PM +0300, Nicola Tuveri wrote: > topic: Hold online weekly OTC meetings starting on Tuesday 2020-10-13 >and until 3.0 beta1 is released, in lieu of the weekly "developer >meetings". +1 Kurt
Re: Vote proposal: Technical items still to be done
On Wed, Oct 07, 2020 at 12:35:28PM +0100, Matt Caswell wrote: > The following items are required prerequisites for the first beta release: [...] > * Address 3.0beta1 milestones. So we now have a list here, with the last item pointing to a different list. I suggest that we only have 1 list, and that we make github issues for anything that doesn't have an issue yet, and it to the milestone. It would at least be easier to track the progress. We also talked about freezing the milestone at some point. We intend to go over the 3.0.0 milestone PRs/issues, and see if any of those need to be moved to the 3.0.0 beta1 milestone. I assume that if we have done that, that we'll freeze it. We can then try to estimate how long it will take before beta1. Kurt
Re: Vote proposal: Private keys can exist independently of public keys
On Wed, Oct 07, 2020 at 12:29:10PM +0100, Matt Caswell wrote: > Issue #12612 exposes a problem with how we handle keys that contain > private components but not public components. > > There is a widespread assumption in the code that keys with private > components must have public components. There is text in our public > documentation that states this (and that text dates back to 2006). > > OTOH, the code has not always enforced this. Issue #12612 describes a > scenario where this has not historically been enforced, and it now is in > the current 3.0 code causing a regression. > > There are differences of opinion on how this should be handled. Some > have the opinion that we should change the model so that we explicitly > allow private keys to exists without the public components. Others feel > that we should continue with the old model. It seems to me that we have various ways forward: 1) Enforce that a private key requires the public key 2) Don't enforce it, just give an error when you try to use the public key and it's not available. 3) Make it work for the same cases that worked with 1.1.1 4) Generate the public key from the private key 5) Have some kind of transition where we do 2), 3) or 4) in 3.0, but will move to 1) at some later point. 6) do 2), but enforce it in the fips provider I don't know if we do any any kind of consistency checks on the key now when it's loaded. But 2) would then imply that the check is skipped instead of returning an error. Kurt
Re: Tracking important issues
On Wed, Sep 23, 2020 at 08:51:28PM +0200, Kurt Roeckx wrote: > Hi, > > I would like to have a system so that we can tag issues as > important. But I think they fall in a few categories: > - Features for the next minor/major release (so 3.1 or 4.0) > that we find important. I've created a new milestone for that: > https://github.com/openssl/openssl/milestone/18 (Post 3.0.0) > > We've also had a Post 1.1.1 milestone, but that seems to be just > things that didn't block the 1.1.1 release, maybe some more > things can be moved over. > > I suggest we do not add all feature requests to the new > milestone, so that we can have some kind of overview. > - Features we want in before beta 1: The 3.0.0 beta1 milestone > - Bugs that need to get fixed before the 3.0.0 release: > currently using the 3.0.0 milestone > - Important bugs that affect the stable releases. I've started > tagging bugs that have "triaged: bug" also with the branches > that are affected. But that doesn't say how important it is. > I have 2 proposals for that: > - Create a milestone for them, like 1.1.1-stable. In cases we > have multiple supported branches, we can add for instance a > 3.0-stable and use the oldest branches that's a affected > as the target. This would at least match what we do now > with the "3.0.0" milestone. > - Create a label for the severity. I'm not sure we need things > like "severity: minor", but it might be useful too. So I've created the "severity: important" label, and started tagging some issues with it. Kurt
Re: VOTE: OTC meeting will be called for next Tuesday
On Wed, Sep 30, 2020 at 01:57:34PM +, Dr. Matthias St. Pierre wrote: > topic: OTC meeting will be called for next Tuesday +1, but wondering why this needs a vote. Kurt
Re: VOTE: Accept the OTC voting policy as defined:
On Mon, Sep 28, 2020 at 12:02:07PM +, Dr. Matthias St. Pierre wrote: > topic: Accept the OTC voting policy as defined: > >The proposer of a vote is ultimately responsible for updating the > votes.txt >file in the repository. Outside of a face to face meeting, voters > MUST reply >to the vote email indicating their preference and optionally their > reasoning. >Voters MAY update the votes.txt file in addition. > >The proposed vote text SHOULD be raised for discussion before calling > the vote. > >Public votes MUST be called on the project list, not the OTC list and > the >subject MUST begin with "VOTE:". Private votes MUST be called on the >OTC list with "PRIVATE VOTE:" beginning subject. +1 Kurt
Re: Freeze?
On Thu, Sep 24, 2020 at 12:33:56PM +1000, Dr Paul Dale wrote: > I’m seeing quite a bit of activity going on which isn’t related to the > 3.0beta1 milestone. > We’re well past the cutoff date announced for new features in the code. > > Should we be limiting the “new” stuff going in? > > I’m fine with bug fixes, they make sense. I’m fine with the list of beta1 > pull requests continuing. > It’s the rest that is more concerning. I think we should stop accepting any new changes that are not clearly related to fixing issues that have been introduced during the development of 3.0. Of course, bugs can always be fixed. We've previously announced the deadline for beta 1 to be the 8th of September. Clearly not everything needed is ready. But at some point we will have to make the beta 1 release. Kurt
Tracking important issues
Hi, I would like to have a system so that we can tag issues as important. But I think they fall in a few categories: - Features for the next minor/major release (so 3.1 or 4.0) that we find important. I've created a new milestone for that: https://github.com/openssl/openssl/milestone/18 (Post 3.0.0) We've also had a Post 1.1.1 milestone, but that seems to be just things that didn't block the 1.1.1 release, maybe some more things can be moved over. I suggest we do not add all feature requests to the new milestone, so that we can have some kind of overview. - Features we want in before beta 1: The 3.0.0 beta1 milestone - Bugs that need to get fixed before the 3.0.0 release: currently using the 3.0.0 milestone - Important bugs that affect the stable releases. I've started tagging bugs that have "triaged: bug" also with the branches that are affected. But that doesn't say how important it is. I have 2 proposals for that: - Create a milestone for them, like 1.1.1-stable. In cases we have multiple supported branches, we can add for instance a 3.0-stable and use the oldest branches that's a affected as the target. This would at least match what we do now with the "3.0.0" milestone. - Create a label for the severity. I'm not sure we need things like "severity: minor", but it might be useful too. Kurt
Re: 3.0 beta 1 milestone
On Thu, Sep 17, 2020 at 06:49:19PM +0200, Kurt Roeckx wrote: > - It doesn't go into 3.0. No idea what the best way to tag them > is. So I've created a "Post 3.0.0" milestone for that. Kurt
Re: Beta1 PR deadline
On Fri, Sep 11, 2020 at 11:07:48AM +, Dr. Matthias St. Pierre wrote: > For a more accurate and timely public overview over the current state of the > blockers, > it might be helpful to manage them via the 3.0.0 milestone > > https://github.com/openssl/openssl/milestone/15 > > Some of the tickets listed below were already associated to the milestone, > the others > were added by me now. I think the 3.0.0 milestone is what we expect to be in the 3.0.0 release, not the beta release. That is bug fixes don't need to be in the beta release, but if it adds new functionallity it needs to be in the beta release. Kurt
Re: Beta1 PR deadline
On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote: > Please can anyone with PRs that they wish to have included in OpenSSL > 3.0 beta1 ensure that they are merged to master by 8th September. So that date has passed now. Can someone give an overview of what we think is still needed to be done before the beta 1 release? Are there open PRs for everything? Do we a milestone on github to indicate which PRs need to go in before beta1? Kurt
Re: Backports to 1.1.1 and what is allowed
On Fri, Jun 19, 2020 at 10:29:24PM +0100, Matt Caswell wrote: > > My immediate reaction to that is no - it shouldn't go to 1.1.1. That > would impact a very high proportion of our user base. So is risk an important factor? How do you judge the risk? By the size of the change? Kurt
Re: Reducing the security bits for MD5 and SHA1 in TLS
On Wed, May 27, 2020 at 12:14:13PM +0100, Matt Caswell wrote: > PR 10787 proposed to reduce the number of security bits for MD5 and SHA1 > in TLS (master branch only, i.e. OpenSSL 3.0): > > https://github.com/openssl/openssl/pull/10787 > > This would have the impact of meaning that TLS < 1.2 would not be > available in the default security level of 1. You would have to set the > security level to 0. > > In my mind this feels like the right thing to do. The security bit > calculations should reflect reality, and if that means that TLS < 1.2 no > longer meets the policy for security level 1, then that is just the > security level doing its job. However this *is* a significant breaking > change and worthy of discussion. Since OpenSSL 3.0 is a major release it > seems that now is the right time to make such changes. > > IMO it seems appropriate to have an OMC vote on this topic (or should it > be OTC?). Possible wording: So should that be an OMC or OTC vote, or does it not need a vote? Kurt
Re: Travis jobs not getting started
On Fri, Jun 05, 2020 at 01:27:20PM +0200, Tomas Mraz wrote: > Apparently the travis jobs are not getting started anymore for some > reason. > > It happened to me on the GitHub linux-pam project and the solution (or > workaround) was to migrate the project to the travis-ci.com. > > I just did it by following the instructions in this document: > https://docs.travis-ci.com/user/migrate/open-source-repository-migration/ I've tried to do it, but it doesn't seem to be working, it says it can't find the repository. Kurt
Re: Unexpected EOF handling
On Mon, May 11, 2020 at 06:38:40PM +0300, Dmitry Belyavsky wrote: > Dear Tomas, > > I'm not sure this is the best possible solution because it makes the > application developers doing extra compile-time checks. This is a very minimal change they they need to do that doesn't have much risk. But if you have a different suggestion, please say so. > But anyway, is it a final decision and the patch can be amended or we are > waiting for objections some more time? I think there is just a concensus that that is the way forward. There has not been a vote, nor do I see a reason to hold a vote at this point. Kurt
Re: Unexpected EOF handling
On Fri, May 08, 2020 at 01:27:00PM +0300, Dmitry Belyavsky wrote: > On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx wrote: > > > > So I think the suggestion is to have this: > > - By default, SSL_ERROR_SSL is returned with > > SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be > > marked invalid. > > - With an option, SSL_ERROR_ZERO_RETURN is returned, the session > > will stay valid. > > > > If I remember correctly, session resumption is a way to significantly > reduce a server's workload. > So I think that by default (and maybe the only option) we should prefer the > old behaviour. If it's a fatal error, the session should be marked as bad. So if you want that by default we don't mark is as bad, the default should be that it's a non-fatal error, and we don't want to return SSL_ERROR_ZERO_RETURN by default. SSL_ERROR_SYSCALL with errno 0 does not look like a good long term API to indicate a non-fatal error. And a different error is also not what people want. Kurt
Re: Unexpected EOF handling
On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote: > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > > So I think we need at least to agree on: > > > - Do we want an option that makes the unexpected EOF either a fatal > > > error or a non-fatal error? > > > - Which error should we return? > > > > This is an excellent summary of the current situation. > > > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a > > long term solution. It's a very confusing API for new applications to > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except > > when its not. SSL_ERROR_SYSCALL should mean fatal error. > > > > That said I also recognise that it is apparently commonplace to shut > > down a TLS connection without sending close_notify - despite what the > > standards may say about it (and TBH we can hardly claim the moral > > high > > ground here since s_server does exactly this - or at least it does in > > 1.1.1 and did until very recently in master). > > > > But we do have to consider usages beyond HTTPS. I have no idea if > > this > > occurs in other settings or not. > > > > Perhaps what we need is an option for "strict shutdown". With strict > > shutdown "off" we could treat EOF as if we had received a > > close_notify > > gracefully (and don't invalidate the session). Presumably existing > > code > > would be able to cope with that??? > > Yes, existing code would be able to cope with that with one important > exception that I am going to talk about below. > > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in > > master). > > > > I'm not sure though what the default should be. > > In case we go with this solution, which would be acceptable I think, we > MUST NOT EVER make it the default because existing applications that > depend on the existing way how the unclean EOF condition is returned > might actually depend on it to detect the truncation attack. I agree that we should not return SSL_ERROR_ZERO_RETURN by default on an unexpected EOF. If the default behaviour should be to make it a non-fatal error, like the old behaviour is, I would really prefer a different error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL. So I think the suggestion is to have this: - By default, SSL_ERROR_SSL is returned with SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be marked invalid. - With an option, SSL_ERROR_ZERO_RETURN is returned, the session will stay valid. Kurt
Re: Unexpected EOF handling
On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote: > > Actually the coincidence is that the errno is set to 0 on EOF. So yes, > we should explicitly clear the errno on EOF so any leftover value from > previous calls does not affect this. On EOF, errno is normally not modified. It's value is not defined if no error is returned. It is not guaranteed to be 0 on success or EOF. It can be modified, because the implementation might have done other system calls that did return an error. But a simple test shows that it's not modified on my system. Kurt
Re: Unexpected EOF handling
On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote: > From application developer side of view for protocols that do not > depend on SSL detecting the truncation I think inventing a different > behavior for this condition than the existing one as of 1.1.1f would be > clearly wrong. Switching on a SSL_OP if that newly provided OP is a > trivial change to an application that needs to accommodate various > versions of OpenSSL (and I am not talking about forks), however > switching on a SSL_OP and also add another special error case is much > more complicated change and has potential for bringing regressions in > the applications that need to do it. Of course, just adding a call to get the old behaviour back is a very easy change. But I currently don't see how a different error is that much more complicated. > Is there really another situation where SSL_ERROR_SYSCALL with errno 0 > could be returned apart from the unclean EOF condition? > > I can't really think of any. It's not because we can't think of any other case that there aren't any. I also have a problem with checking errno being 0. We don't set errno. There is no reason to assume that errno is set to any value. errno can be modified on a succesful call. That errno is 0 is just a coincidence. If we're going to document that, we should actually make sure that that is the case. I think the other property of the old behaviour is that we don't add anything to the error stack. > So I would be just for properly documenting the condition and keeping > it as is if the SSL_OP to ignore unclean EOF is in effect. And also don't add an option for applications that do want to get a fatal error? Kurt
Unexpected EOF handling
Hi, We introduced a change in the 1.1.1e release that changed how we handled an unexpected EOF. This broke various software which resulted in the release of 1.1.1f that reverted that change. In master we still have the 1.1.1e behaviour. The change itself is small, it just calls SSLfatal() with a new error code. This has at least 2 effects: - The error code was changed from SSL_ERROR_SYSCALL with errno 0 to SSL_ERROR_SSL with reason code SSL_R_UNEXPECTED_EOF_WHILE_READING - The session is marked as in error, and so can't be used to resume. There is code written that now checks for the SSL_ERROR_SYSCALL with errno 0 case, while we never documented that behaviour. The 1.1.1 manpage of SSL_get_error() currently reports this as a bug and that it will change to SSL_ERROR_SSL / SSL_R_UNEXPECTED_EOF_WHILE_READING. Code that checks the SSL_ERROR_SYSCALL with errno 0 seem to fall in at least 2 categories: - Ignore the error - Check for the error, for instance in a test suite Not sending the close notify alert is a violation of the TLS specifications, but there is software out there doesn't send it, so there is a need to be able to deal with peers that don't send it. When the close notify alert wasn't received, but we did get an EOF, there are 2 cases: - It's a fatal error, the protocol needs the close notify alert to prevent a truncation attack - The protocol running on top of SSL can detect a truncation attack itself, and does so. It doesn't need the close notify alert. It's not a fatal error. They just want to check that that is what happened. The problem is that we can't make a distiction between the 2 cases, so the only thing we can do currently is to look at it as a fatal error. So the documentation was changed to say that if you're in the 2nd cases, and need to talk to a peer that doesn't send the close notify alert, you should not wait for the close notify alert, so that you don't get an error. The alternative is that we add an option that does tell us if we should look at it as a fatal error or not. There is at least a request that we keep returning the old error code (SSL_ERROR_SYSCALL with errno 0). I think that from an API point of view this is very confusing. We'd then have SSL_ERROR_SYSCALL as documented that it's fatal, except when errno is 0. If errno is 0, it can either be fatal or not, and we're not telling you which one it is. I think we also can't guarantee that SSL_ERROR_SYSCALL with errno 0 is always the unexpected EOF, we returned that combination because of a bug in OpenSSL. So I think we need at least to agree on: - Do we want an option that makes the unexpected EOF either a fatal error or a non-fatal error? - Which error should we return? Kurt
Re: Improving X.509 certificate validation errors
On Wed, Mar 25, 2020 at 10:21:36PM -0700, Benjamin Kaduk wrote: > I tihnk it's an interesting idea. To me, perhaps the most valuable part > would be to accumulate a corpus of certificates/chains that are malformed > or fail to validate due to a wide variety of errors, almost akin to a > fuzzing corpus. I'd also be curious (though I'm not entirely sure how > large a practical impact it would have) to perform a clustering analysis > across different X.509 implementations and see if different implementations > produce different distributions of errors. (That is, we might expect each > implementation to have an error for "not valid yet", "expired", "missing > required ASN.1 field", etc.; each implementation will have a different > error string, of course, but if we group all certificates that produce the > same error with the same implementation together, we have a bunch of > different clusters. Repeating the clustering across all implementations > lets us compare the different distributions, and examine certificates that > end up in a different cluster in different implementations.) That's what frankencert did. Kurt
Re: Deprecations
On Mon, Mar 02, 2020 at 11:41:57AM +, Matt Caswell wrote: > > > On 28/02/2020 23:43, Dr Paul Dale wrote: > > Any suggestions for a consensus on this thread? > > I think we can probably agree that: > > - Command option deprecations should be handled better > - We should look at whether we can resurrect some of the "old" commands > (possibly by writing them as wrappers for genpkey, pkey and pkeyutl) What about at least pointing to the alternative function in the documentation? Kurt
Re: OpenSSL Logo (was: New GitHub Project Landing Page)
On Thu, Feb 27, 2020 at 01:23:16PM +, Salz, Rich wrote: > Tony Arceri sent me a pure-CSS solution that worked and looked similar. I was about to mention that the website it just text+css. Kurt
Re: Deprecations
On Fri, Feb 21, 2020 at 11:27:55PM +, Matt Caswell wrote: > > > On 21/02/2020 23:18, Kurt Roeckx wrote: > > On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote: > >> > >> dhparam itself has been deprecated. For that reason we are not > >> attempting to rewrite it to use non-deprecated APIs. The informed > >> decision we have made about DH_check use in dhparam is to not build the > >> whole application in a no-deprecated build: > >> > >> *) The command line utilities dhparam, dsa, gendsa and dsaparam have been > >> deprecated. Instead use the pkeyparam, pkey, genpkey and pkeyparam > >> programs respectively. > >> [Paul Dale] > > > > For some reason I seem to have missed various things. > > > > But I think deprecating tools like dhparam, dsaparam in favour of > > genpkey is something that we should reconsider. > > What is your reasoning? > > (I just realised that what the CHANGES entry says is that > dhparam/dsaparam are deprecated in favour of pkeyparam - but actually I > think the equivalent functionality is more split between genpkey and > pkeyparam) Some equivalants: openssl dhparam 2048 openssl genpkey -genparam --algorithm DH -pkeyopt dh_paramgen_prime_len:2048 openssl dsaparam 2048 openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048 If you search internet, you will more than likely find the first ones. They are very easy. I have to look up at the manual page examples to know how to use genpkey. Kurt
Re: Deprecations
On Fri, Feb 21, 2020 at 11:00:10PM +, Matt Caswell wrote: > > dhparam itself has been deprecated. For that reason we are not > attempting to rewrite it to use non-deprecated APIs. The informed > decision we have made about DH_check use in dhparam is to not build the > whole application in a no-deprecated build: > > *) The command line utilities dhparam, dsa, gendsa and dsaparam have been > deprecated. Instead use the pkeyparam, pkey, genpkey and pkeyparam > programs respectively. > [Paul Dale] For some reason I seem to have missed various things. But I think deprecating tools like dhparam, dsaparam in favour of genpkey is something that we should reconsider. Kurt
Re: Deprecations
On Fri, Feb 21, 2020 at 09:50:10AM +, Matt Caswell wrote: > > > On 21/02/2020 08:06, Kurt Roeckx wrote: > > In the apps, a lot of the files define > > OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do > > it. We should stop using the deprecated functions ourself. If > > there is no way to do this using non-deprecated functions, the > > function should probably not have been deprecated in the first > > place. > > > > The apps might have functionality that we want to deprecate too, > > that depends on the deprecated functions. In which case we should > > also mark that as deprecated, and the apps should always build in > > no-deprecation mode. > > I think we have a number of strategies for dealing with deprecated APIs > in the apps depending on the situation: > > 1) Ideally we just rewrite the functionality using non-deprecated APIs The problem is that many of the apps already define OPENSSL_SUPPRESS_DEPRECATED so that you don't know that something you're deprecating is used there without checking for it. The commit I was looking at was ada66e78ef535fe80e422bbbadffe8e7863d457c: Deprecate the low level Diffie-Hellman functions. At least one of the functions being deprecated is DH_check, which is still used by dhparam. Dhparam is our replacement for dh and gendh. I don't know if any of the other function that were deprecated are still used internally or not. The define was added in commit 1ddf2594e18137aeb7ce861e54f46824db76e36f, and so when DH_check later got deprecated, nobody noticed that the now deprecated function is still being used. I think the replacement function is EVP_PKEY_param_check(). DH_check is not mentioned as deprecated in the manual. Kurt
Deprecations
Hi, We seem to be deprecating a lot of the old APIs, which I think is a good thing. But I think we might either be deprecating too much, or not actually using the alternatives ourself. In the apps, a lot of the files define OPENSSL_SUPPRESS_DEPRECATED, which I think is the wrong way to do it. We should stop using the deprecated functions ourself. If there is no way to do this using non-deprecated functions, the function should probably not have been deprecated in the first place. The apps might have functionality that we want to deprecate too, that depends on the deprecated functions. In which case we should also mark that as deprecated, and the apps should always build in no-deprecation mode. We might also be deprecating APIs that we don't use ourself, so it's harder to know if there are alternatives for it. It would also be nice that if you deprecate a function, that you point to the alternative way to do the same thing in the manual. Kurt
Re: crypt(3)
On Sun, Jan 19, 2020 at 11:45:07AM +1000, Dr Paul Dale wrote: > I meant “what default makes the most sense for the passwd command line > application?” > It was crypt which is deprecated. Should it be BSD’s MD5? One of the SHA2 > based algorithms? Or should it produce an error if no algorithm is selected? I would actually like to go for something modern in that case, like argon2 (argon2id). We have an open issue (https://github.com/openssl/openssl/issues/4091) and pull request (https://github.com/openssl/openssl/pull/9444) for argon2. PHP seems to have made a format for it that's compatible with crypt(): https://wiki.php.net/rfc/argon2_password_hash_enhancements But the argon2 RFC hasn't been published yet, so I think that might need to wait. The only thing that we support currently that makes sense as a default is -5 (sha256) and -6 (sha512). I suggest you go with -6. Kurt
Re: crypt(3)
On Sat, Jan 18, 2020 at 10:47:04AM +1000, Dr Paul Dale wrote: > Could the people who work with distros confirm this default choice or suggest > what they use please? I'm not sure what you're asking, but crypt() has moved on from using DES like 20 years ago, see crypt(5). Kurt
Re: crypt(3)
On Fri, Jan 17, 2020 at 04:31:06PM +1000, Dr Paul Dale wrote: > I’ve got several choices: > Leave them public and unchanged — that is, don’t deprecate these two > functions yet. > Deprecate them and add KDFs to replace them. > Deprecate them, leave them alone and hope they go away painlessly at some > point. I really see no point in adding something that we at the same time would like to remove. Just deprecate it. Kurt
Re: Legacy Provider
On Tue, Jan 07, 2020 at 09:57:55AM +1000, Dr Paul Dale wrote: > The refactoring/FIPS work needs the question resolved about loading the > legacy provider or not by default. We’ve been through this before on the > project list [1] and in at least one PR [2]. > > I expect that its resolution will require an OMC vote. Why OMC and not OTC? Kurt
Re: Build failures on master?!
On Mon, Nov 18, 2019 at 09:48:38PM +, Dr. Matthias St. Pierre wrote: > The last 19 commits on https://github.com/openssl/openssl/commits/master, > starting from Nov 14 have a red cross from the CIs. What's going on again? I have filed 2 issues on Nov 9 that that caused the CIs to fail, that that haven't been closed yet. > My personal impression is that builds on master are failing 50% of the time. > > It is really tedious to check pull requests for build errors just to find > that those errors > are well known failures from master. In particular, the krb5 an pyca tests > are notoriously > failing. Are there any plans to fix them or disable them? > > 95-test_external_krb5.t (Wstat: 256 Tests: 1 Failed: 1) > 95-test_external_pyca.t (Wstat: 256 Tests: 1 Failed: 1) > > Clean builds on master should have highest priority. Because if there are too > many red > crosses, nobody cares about them anymore. Note that they are also broken in the 1.1.1-stable branch. At least pyca is something you should be able to fix with a new upstream version. Kurt
New audit before 3.0 release
Should we let someone do a new audit before the 3.0 release? Kurt
Re: Thread sanitiser problems
On Tue, Jul 30, 2019 at 12:41:16PM +0200, Matthias St. Pierre wrote: > On 30.07.19 11:59, Kurt Roeckx wrote: > > On Tue, Jul 30, 2019 at 12:42:33PM +1000, Dr Paul Dale wrote: > > > Overly simplified, the problem boils down to the CTR DRBG needing an AES > > > CTR cipher context to work. When creating the former, a recursive call > > > is made to get the latter. > > I'm not sure what you mean with "CTR" both times. > > > > Are you saying that an AES requires a DRBG now? > > > > No. Pauli simply meant that the CTR DRBG utilizes an EVP_CIPHER_CTX for its > internal implementation. I currently fail to see how that's a problem, unless that EVP_CIPHER_CTX tries to use a DRBG. Kurt
Re: Thread sanitiser problems
On Tue, Jul 30, 2019 at 12:42:33PM +1000, Dr Paul Dale wrote: > Overly simplified, the problem boils down to the CTR DRBG needing an AES CTR > cipher context to work. When creating the former, a recursive call is made > to get the latter. I'm not sure what you mean with "CTR" both times. Are you saying that an AES requires a DRBG now? Kurt
Re: Two Travis Jobs are failing on master
On Tue, Jul 23, 2019 at 09:15:22PM +, Dr. Matthias St. Pierre wrote: > It looks like currently two jobs of every travis build are failing on master, > each with two different tests. > Since this affect the builds of the pull requests, it would be nice if they > could be fixed. Is anybody taking > care of the problem already? Is is related to 9442? Note that the failing tests are part of the extended tests, so we don't see a problem during pull requests. Pull requests pass without problems. It seems that we don't notice things even if master is broken for a while, because they are only tested after they've been commited, and it doesn't affect other pull requests. I wonder if we can somehow get notificated of that. Kurt
Re: Do we really want to have the legacy provider as opt-in only?
On Tue, Jul 16, 2019 at 03:06:28PM -0400, Viktor Dukhovni wrote: > On Mon, Jul 15, 2019 at 02:27:44PM +, Salz, Rich wrote: > > > >>DSA > > > > > > What is the cryptographic weakness of DSA that you are avoiding? > > > > It's a good question. I don't recall the specific reason why that was > > added to > > the list. Perhaps others can comment. > > > > The only weakness I know about is that if you re-use the nonce, the private > > key is leaked. It's more brittle than RSA-PKCS, but not as flawed as RC4. > > > > I think this should be removed from the "legacy" list unless someone can > > point out why it's like the others in the list. > > 1. DSA is not supported in TLS 1.3. > 2. DSA is almost never used with TLS 1.2, the public > CAs and the vast majority of users employ RSA. > 3. Historical DSA was limited to 1024-bit keys and SHA-1. > IIRC we now support stronger combinations, but these > are not widely used. > 4. As mentioned key disclosure is more likely than with RSA. > 5. Attack-surface reduction. If DSA is almost never used, > why enable it by default? > > I might note that I don't count myself amont the "crypto maximalists" > And I'm generally of the "raise the ceiling not the floor" mindset, > RFC7435 and all that. However, once an algorithm is sufficiently > disused (raising the ceiling worked, and everybody we care about > has moved on) it is then time to turn out the lights. There used to be DSA certificates used in TLS, but the last one expired years ago. DSS based ciphers are also disabled by default since 1.1.0. Kurt
Re: Do we really want to have the legacy provider as opt-in only?
On Mon, Jul 15, 2019 at 02:58:42PM +0200, Tomas Mraz wrote: > Wouldn't it be better to make the legacy provider opt-out? I.E. require > explicit configuration or explicit API call to not load the legacy > provider. I'm not even sure why they need to move to a different provider (at this time). Instead I think we should have a mechanism to enable/disable the individual algorithms, and still have everything in the default provider, possibly disabled by default. At some point in the future we could remove the code from OpenSSL, and move it to different repository that only contains such legacy code that we no longer ship as part of OpenSSL. Kurt
Re: Start up entropy gathering
On Thu, Jun 13, 2019 at 05:06:16PM +1000, Dr Paul Dale wrote: > > The second suggestion is broadly similar but requires a file containing > entropy that persists across reboots. This alternative requires a more > management: the entropy file once read needs to be rewritten immediately (and > ideally on shutdown as well). It also introduces a new attack vector against > the entropy storage. It also isn’t possible to skip the entropy file > read/rewrite sequence because it is impossible to determine if /dev/urandom > has actually been seeded. I’ve not attempted to code this, persistent files > containing seed material potentially introduce other problems. This is what init systems have always done. I see no need to also do it. They have a policy not to credit that the entropy from that file, I see no reason why we should override that policy. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 07:04:57PM -0400, Viktor Dukhovni wrote: > On Sat, Jun 08, 2019 at 12:54:36AM +0200, Kurt Roeckx wrote: > > > On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote: > > > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote: > > > > > > > > For older kernels you install rng-tools that feeds the hwrng in > > > > the kernel. > > > > > > Which works for me, and is pretty much the point I'm trying to make. > > > Then, read /dev/random once early at boot, and do nothing special > > > libcrypto (safely use /dev/urandom). > > > > The only thing rng-tools will actually solve is the starvation > > issue. No service will depend on it, since they don't have any > > relationship with it. Nor can you wait for it, it's not because > > it's started that it has initialized the kernel. I think I've also > > seen reports that it got started too late, actually after a > > services that wants to ask the kernel for random numbers. > > Then a different service can be developed that does block just once > at boot, and tries to obtain entropy from a configurable set of > sources (to avoid or reduce unbounded delay, and mix in more > independent sources). That's all very nice, but nobody is going to run that. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 03:37:07PM -0400, Viktor Dukhovni wrote: > > On Jun 7, 2019, at 3:25 PM, Kurt Roeckx wrote: > > > > For older kernels you install rng-tools that feeds the hwrng in > > the kernel. > > Which works for me, and is pretty much the point I'm trying to make. > Then, read /dev/random once early at boot, and do nothing special > libcrypto (safely use /dev/urandom). The only thing rng-tools will actually solve is the starvation issue. No service will depend on it, since they don't have any relationship with it. Nor can you wait for it, it's not because it's started that it has initialized the kernel. I think I've also seen reports that it got started too late, actually after a services that wants to ask the kernel for random numbers. An other solution might be that we enable rdrand/rdseed by default as entropy source, after getentropy() and before /dev/urandom. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 07:01:30PM +, Salz, Rich wrote: > > >The kernel actually already does this in recent versions, if > configured to do it. > > "The" kernel. Which one is that? Which operating system? > > Modern Linux is fine. Is that all we care about? This whole discussion has only been about Linux, we only define DEVRANDOM_WAIT on Linux. I think all other OSs have a sane /dev/urandom, but I'm not sure about NetBSD. > 1.1.1c made Solaris (and possibly others) more secure. I would be > disappointed if 1.1.1d took that away and tried to rationalize that "it's not > my job." *YOU'RE A CRYPTOGRAPHIC LIBRARY* Do you have a reference that Solaris allows reading from /dev/urandom before it's been initialized? Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 03:08:24PM -0400, Viktor Dukhovni wrote: > > On Jun 7, 2019, at 2:41 PM, Kurt Roeckx wrote: > > > >> This is not the sort of thing to bolt into the kernel, but is not > >> unreasonable for systemd and the like. > > > > The kernel actually already does this in recent versions, if > > configured to do it. > > We're talking about what to do with for older kernels. For older kernels you install rng-tools that feeds the hwrng in the kernel. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 02:31:54PM -0400, Viktor Dukhovni wrote: > > That's a different issue. What I was suggesting was a service that > waits for seeding to be ready. So that other services can depend > on that service, with that service using various sources to adequately > seed the kernel RNG, with configurable additional sources beyond the > save file, possibly with a non-zero entropy estimate. Thus, for example, > a virtual machine or container might make use of an interface to get a > a trusted seed from the host hypervisor/OS. Or a physical host might > trust its TPM, ... > > This is not the sort of thing to bolt into the kernel, but is not > unreasonable for systemd and the like. The kernel actually already does this in recent versions, if configured to do it. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 01:28:30PM -0400, Viktor Dukhovni wrote: > > I think that having the RNG behaviour capriciously different on > different systems based on the whims of whoever built the library > for that system is not a good idea. OpenSSL should provide an RNG > that does not block "unexpectedly", indefinitely, and unpredictably. > > Where "unexpectedly", means except possibly early at boot time, but > ideally waiting for boot-time entropoy is something that systemd > and the like take care of, and application start scripts can just > register a dependency on some sort of "entropy" service, whose > successful initialization is sufficient to ensure adequately secure > non-blocking seeding of applications via one of getentropy(), > getrandom(), /dev/urandom... > > That is, I'd expect most of the work for ensuring adequate entropy > to happen outside libcrypto, except for perhaps enabling some > additional sources that may be available on various systems. It seems unlikely that anything related to this will ever change, but we can always ask. The reason I think nothing will change is that the problem is already solved, use getentropy()/getrandom(). The init system would need to create this kind of service, and then all software not using getentropy()/getrandom() would need to depend on that service. It would be eaier to just switch that software to use getentropy()/getrandom(). Changing the init system, means that this will only work for new versions of an OS. But on those new versions we already use getentropy()/getrandom(). What we want to support is people that use an old OS, but run a new version of OpenSSL on it. That is, people that do not use the OS provided OpenSSL version. Kurt
Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT
On Fri, Jun 07, 2019 at 10:18:32AM +0200, Tomas Mraz wrote: > > From the point of view of distribution maintainer of OpenSSL I would > say what we had in 1.1.1 before the introduction of DEVRANDOM_WAIT had > no real problems for us. Introducing DEVRANDOM_WAIT didn't cause any change for us, because we use getentropy(), and a recent kernel. But even systems that use getentropy() with an older kernel can have a large delay after boot. Kurt
Vote proposal: votes should get discussed first
Hi, I would like to propose the following vote: All public votes should be discussed on the openssl-project list before a vote is called. The minimum time between a proposal and calling for a vote is 1 week. If the proposal is changed, the 1 week period restarts.
Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change
On Thu, Jan 31, 2019 at 02:19:28PM -0600, David Benjamin wrote: > On Thu, Jan 31, 2019 at 2:01 PM Matt Caswell wrote: > > > > > On 31/01/2019 18:50, David Benjamin wrote: > > > We will see if this damage turns out fatal for KeyUpdate, but OpenSSL > > can at > > > least help slow its spread by issuing a fix > > > > That's precisely what PR 8096 does. > > > > > > > As a heuristic for API design: if the caller needs to know the > > implementation > > > details of OpenSSL to understand what this API does, the API is no good. > > > Existing code cannot possibly predict how OpenSSL's implementation will > > evolve > > > over time, so there is no way to use such an API in a future-proof way. > > Do not > > > introduce such APIs. > > > > The info callback has been around a *long* time. In fact OpenSSL did not > > introduce it at all - we inherited it from SSLeay. Arguments about whether > > it is > > a good API or not don't help the issue at hand. The API exists, > > applications use > > it, and so (for now at least) we continue to support it. > > > > Given that it already existed we had to make a decision about how it was > > going > > to work in the presence of TLSv1.3. We did what we believed to be the > > correct > > thing at the time. The changes were pretty minimal and we tried to keep > > things > > as close to what existing users of the callback would expect. It turns out > > we > > got it wrong. > > > > Right, but SSL_CB_POST_HANDSHAKE_START and SSL_CB_POST_HANDSHAKE_END are > new. It seems best to just omit it, so OpenSSL is not tied to the nebulous > notion of "post-handshake exchange". > > I.e. don't bracket post-handshake things with START/END at all. Matt, do you have any comment on this? Can we go forward with this? Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Proposed vote text for the SSL_CB_HANDSHAKE_START change
On Tue, Jan 29, 2019 at 02:07:09PM +, Matt Caswell wrote: > So I plan to start the vote soon for merging PR#8096 and backporting it to > 1.1.1. This is a breaking change as previously discussed. > > My proposed vote text is as follows. Please let me know asap of any feedback. > Otherwise I will start the vote soon. > > "master and 1.1.1 will be updated to use SSL_CB_POST_HANDSHAKE_START and > SSL_CB_POST_HANDSHAKE_END to signal the start and end of a post handshake > message exchange in the info callback (replacing SSL_CB_HANDSHAKE_START and > SSL_CB_HANDSHAKE_END)." So my proposal would be: Don't call the callback for post handshake messages. (It could use some rewording.) Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
