Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Kurt Roeckx
On Thu, Jun 07, 2018 at 12:07:34PM -0500, Benjamin Kaduk wrote:
> On Thu, Jun 07, 2018 at 05:55:27PM +0200, Andy Polyakov wrote:
> > > Regarding general use of other libraries, please think carefully before 
> > > voting, 'cause this *is* tricky. If you have a look, you will see that we 
> > > *currently* depend on certain standard libraries, such as, for example, 
> > > libdl.
> > 
> > One has to recognize that each dependency has to be justified. Sometimes
> > you don't have a choice. For example if you want to talk network on
> > Solaris, you have to link with -lsocket -lnsl. It's just part of the
> > game. But in cases one has a choice, well, one has a choice to *make*.
> > And key question is how do you anchor it. It's only natural to have as
> > little dependencies as possible, so question is what would justify extra
> > dependency.
> 
> Taking off on a bit of a tangent, how much justification did we go
> through when adding pthreads as a dependency.  I have not been
> following very much (Kurt would know more), but apparently in Debian
> there are some issues regarding (statically linked?) applications
> and libraries that use libcrypto but do not explicitly link with
> -pthread.  "Issues" here being, IIRC, crashes at runtime.

I haven't really followed it, I just saw some mentionng of it on
IRC. At least static linkig glibc itself is complicated. I guess
it's also complicated because libc itself contains stubs for the
pthread functions, so at least the order of the libraries will be
important when linking staticly. But I didn't read anything about
crashes, I might have missed things.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries

2018-06-07 Thread Kurt Roeckx
On Thu, Jun 07, 2018 at 05:19:48PM +0200, Richard Levitte wrote:
> Regarding general use of other libraries, please think carefully before 
> voting, 'cause this *is* tricky. If you have a look, you will see that we 
> *currently* depend on certain standard libraries, such as, for example, 
> libdl. And perhaps we should also mention the pile of libraries used with 
> windows.

We also started depending on pthread in 1.1.0 ...


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Open Source Summit Europe

2018-06-19 Thread Kurt Roeckx
On Tue, Jun 19, 2018 at 06:01:19PM +0100, Mark J Cox wrote:
> Just as a FYI in case anyone is interested in an OpenSSL-related
> submission (if you want to do something joint with me, I'm interested
> and local lol).
> 
> > Conference: Open Source Summit Europe
> > Location: Edinburgh
> > Dates: October 22 – 24
> >
> > Deadline for speaking submissions: July 1
> 
> https://events.linuxfoundation.org/events/open-source-summit-europe-2018/

You've suggested to do an OMC meeting there before.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-01 Thread Kurt Roeckx
On Fri, Jun 01, 2018 at 01:20:17PM -0500, Benjamin Kaduk wrote:
> On Fri, Jun 01, 2018 at 12:23:39PM +, Salz, Rich wrote:
> > >I think that the gist of the difference of opinion is whether it's OK
> > to use locale dependent functions such as mbstowcs in libcrypto or
> > not.
> >   
> > 
> > Thanks for the summary.
> > 
> > I am against use locale-dependent functions in libcrypto. 
> 
> I think it's pretty clear (at least to me), that such functions do
> not belong in the normal path.  I'd be open to considering them as a
> fallback attempt to read existing data (as opposed to generating new
> encrypted data), but find Andy's argument about nonpredictability
> (combined with David Woodhouse's enumeration of the various cases
> and the minimal utility of such conversions) to be fairly
> compelling.  That is, I am also against the use of functions that
> depend on the current process's locale in libcrypto.  (I phrase this
> slightly differently, in that functions which take an explicit
> locale to use might still be okay, but are not really portable
> enough for us to use, AIUI.)

So it's my understanding that the library functionw will always
work in UTF-8 then, that's just fine for me.

That would then just mean that the apps need to do the correct
thing and convert it to UTF-8.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-02 Thread Kurt Roeckx
On Fri, Jun 01, 2018 at 07:08:04PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Jun 1, 2018, at 6:47 PM, Richard Levitte  wrote:
> > 
> > Ah, forgot one important detail:  it is well understood that *all*
> > file based objects will get the same requirements, right?  That goes
> > for anything protected through PKCS#5 as well (good ol' PEM
> > encryption, PKCS#8 objects and whatever else I forget...)
> 
> Canonicalize when importing for use with the store API.  Not sure
> whether wchar_t though, just octet string in UTF-8 seems saner.
> That is the password is an opaque byte string, not a character
> string in the platform's encoding of i18n strings.

Whatever we do, it should be clear that we expect the application
to give us the password in a standardized way, so that we can do
with it what is needed.

If it's something the user types, a password really contains
characters, and so whar_t is really a natural way to pass this. It
would at least be very clear to the application what it needs to
do.

whar_t is part of C89, which is still what we target, so it
should be supported. But then we actually have targets that
will most likely not support this and never will.

So the other solution is that this gets passed in a fixed charset
like UTF-8 or UTF-16.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-06 Thread Kurt Roeckx
On Wed, Jun 06, 2018 at 11:23:55AM -0400, David Benjamin wrote:
> 
> Is there a spec citation for this, or some documented experiments against
> other implementations' behavior? (What do Microsoft and NSS do here?) I was
> pondering something similar recently, but things do seem to point at UCS-2
> right now. UCS-2 is indeed an unfortunate historical wart, but X.680 says:

I'm not sure which code I was looking at recently, probably NNS or
gnutls, but it really restricted it to UCS-2.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Help deciding on PR 6341 (facilitate reading PKCS#12 objects in OSSL_STORE)

2018-06-06 Thread Kurt Roeckx
On Wed, Jun 06, 2018 at 09:45:10AM +0200, Richard Levitte wrote:
> Yup.  It seems that BMPString evolved from UCS-2 into UTF-16 at some
> point

The only thing that evolved from UCS-2 to UTF-16 that I know of is
Microsoft Windows. NT used UCS-2, 2000 changed that to UTF-16.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Travis is currently failing

2018-05-01 Thread Kurt Roeckx
On Tue, May 01, 2018 at 11:52:46AM +0200, Kurt Roeckx wrote:
> On Tue, May 01, 2018 at 10:02:31AM +0100, Matt Caswell wrote:
> > 
> > Can anyone shed any light on this error from travis (master branch is
> > failing):
> > 
> > /usr/bin/ld: unrecognized option '--push-state--no-as-needed'
> > /usr/bin/ld: use the --help option for usage information
> > collect2: error: ld returned 1 exit status
> > make[1]: *** [libcrypto.so] Error 1
> > make[1]: Leaving directory `/home/travis/build/openssl/openssl'
> > make: *** [tests] Error 2
> > +/ MAKE TEST FAILED
> 
> We're also not the only one seeing that problem. We also have the
> problem in the 1.1.0-stable branch for the same configuration.
> I have no idea what changed.

And I can't reproduce it.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Travis is currently failing

2018-05-01 Thread Kurt Roeckx
On Tue, May 01, 2018 at 10:02:31AM +0100, Matt Caswell wrote:
> 
> Can anyone shed any light on this error from travis (master branch is
> failing):
> 
> /usr/bin/ld: unrecognized option '--push-state--no-as-needed'
> /usr/bin/ld: use the --help option for usage information
> collect2: error: ld returned 1 exit status
> make[1]: *** [libcrypto.so] Error 1
> make[1]: Leaving directory `/home/travis/build/openssl/openssl'
> make: *** [tests] Error 2
> +/ MAKE TEST FAILED

We're also not the only one seeing that problem. We also have the
problem in the 1.1.0-stable branch for the same configuration.
I have no idea what changed.
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Entropy seeding the DRBG

2018-04-30 Thread Kurt Roeckx
On Mon, Apr 30, 2018 at 06:00:20PM +0200, Richard Levitte wrote:
> 
> So I'd like to have it confirmed that I'm reading this right, that's
> about 0.08 entropy bits per 8 data bits?  Or is it per data bit?

Per symbol, being 8 bits for what you provided.

> Depending on the interpretation, we either have 1 bit of entropy per
> 12 data bits...  or per 100 data bits...  The latter has my heart
> sinking...

It's per 100 bits, and that's really still an overestimate. One of
the models they used was able to predict it that well. It might be
possible to create a better model.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] When to enable TLS 1.3

2018-04-29 Thread Kurt Roeckx
On Sat, Apr 28, 2018 at 04:32:42PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 28, 2018, at 2:41 PM, Kurt Roeckx <k...@roeckx.be> wrote:
> > 
> > So should I send that mail?
> 
> I made some editorial changes to the Wiki section on SNI.
> No strong views on sending the mail...

So I've sent it.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Style guide updates

2018-01-27 Thread Kurt Roeckx
On Sat, Jan 27, 2018 at 01:03:04PM +0100, Kurt Roeckx wrote:
> 
> It's just that there seem to be 2 camps, one saying that all types
> should be signed except when it's to access the bits. The other
> that a size can't be negative so you go for an unsigned type. If
> it's a signed type you could check that they gave you a negative
> value by accident and return an error.

The other argument to go with a signed type it's that it's easier
to write a reverse for loop and not end up with an infite loop.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Style guide update -- summary so far

2018-02-05 Thread Kurt Roeckx
On Mon, Feb 05, 2018 at 08:43:04PM +0100, Dr. Matthias St. Pierre wrote:
> 
> 
> Am 05.02.2018 um 19:13 schrieb Salz, Rich:
> >  
> >
> > Do not put a size after sizeof; do use parens.
> >
> 
> nit: Do not put a /space /after sizeof.
> 
> >  
> >
> > Treat a single-statement with comment as if it were multi-line and use
> > curly braces
> >
> >  
> >
> > if (test()) {
> >
> > /* already alerted */
> >
> > close();
> >
> > }
> >
> >  
> >
> 
> Wasn't there also the suggestion by someone that if one part of an
> if-else statements needs braces that the other part should get some, too?
> 
> if (foo)
> do_this();
> else
> do_that();
> 
> vs.
> 
> if (foo) {
> /* some statements */
> ...
> } else {
> ...
> }

As already pointed out by others, it's mostly already in the style
guide. What is not in it is the combination with a comment:
if (foo)
/* some comment */
do_this();
else
do_that();

And it's been suggested to use curly braces for that.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] VOTE on travel reimbursement policy

2018-02-14 Thread Kurt Roeckx
On Wed, Feb 14, 2018 at 04:06:44PM +, Salz, Rich wrote:
> The policy is in the bureau  (not a public repo) so that we have something 
> concrete to vote on.  It is exactly the same as I posted to the project list 
> before.

I would like to see all votes contain the full text and not
a reference to some commit id.

The call for votes should probably also not go to the project list
based on that current rules say that we vote on the omc list
afaik.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] VOTE on travel reimbursement policy

2018-02-14 Thread Kurt Roeckx
On Wed, Feb 14, 2018 at 10:40:29PM +0100, Richard Levitte wrote:
> In message <20180214212414.ga13...@roeckx.be> on Wed, 14 Feb 2018 22:24:14 
> +0100, Kurt Roeckx <k...@roeckx.be> said:
> 
> kurt> The call for votes should probably also not go to the project list
> kurt> based on that current rules say that we vote on the omc list
> kurt> afaik.
> 
> This is exactly contrary to what we agreed on at the last f2f, apart
> from *certain* votes (such as invitation of new people).

I think that what we agreed to is that the text to vote on should
be discussed on the project list before the vote, and that the
vote should happen on the omc list. Since the vote happens on the
omc list, I see no reason to send the call for votes to the
project list, I only see it as confusing.

Note that I have no problem with voting in public, but then
everybody should vote in public. If some people vote in public and
others don't, the summary might give enough information about what
the others voted. So I think we should either all vote in public,
or nobody should vote in public.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Removal of NULL checks

2018-08-08 Thread Kurt Roeckx
On Wed, Aug 08, 2018 at 08:19:24PM +1000, Tim Hudson wrote:
> We don't have a formal policy of no NULL checks - we just have a few
> members that think we should have such a policy but it has never been voted
> on as we had sufficiently varying views for a consensus approach to not be
> possible.
> 
> Personally I'm in favour of high-level APIs having NULL checks as it (in my
> experience) leads to less bogus error crash reports from users and simpler
> handling in error cleanup logic.
> Otherwise you end up writing a whole pile of if(x!=NULL) FOO_free(x); etc

I think at least Rich would not add checks for NULL in functions
that don't expect to be called with NULL, but on the other hand
moves the NULL check into the free() calls. But in that case, we
also clearly document that it can be called with NULL.

So it's at least not general that there shouldn't be a NULL check.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Releases tomorrow

2018-08-14 Thread Kurt Roeckx
On Tue, Aug 14, 2018 at 01:50:39AM +, Salz, Rich wrote:
> >- If we're going to make any changes for issue 6904 (broken pipe for
> clients that only write/server that only reads), then we should do that
> 
> Yeah, I don't like the library messing with signals tho.

I don't think it's about signals, but about write() returning
EPIPE (or ECONNRESET).


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Forthcoming OpenSSL releases

2018-08-07 Thread Kurt Roeckx
On Tue, Aug 07, 2018 at 04:15:52PM +0200, Andy Polyakov wrote:
> > Forthcoming OpenSSL releases
> > 
> 
> I have some RSA hardening fixes in pipeline...

Do you suggest we wait with a release on that, or can we just put
it in the next release?


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Forthcoming OpenSSL releases

2018-08-12 Thread Kurt Roeckx
On Tue, Aug 07, 2018 at 04:52:28PM +0200, Andy Polyakov wrote:
> >>> Forthcoming OpenSSL releases
> >>> 
> >>
> >> I have some RSA hardening fixes in pipeline...
> > 
> > Do you suggest we wait with a release on that, or can we just put
> > it in the next release?
> 
> I should be able to pull it off in before release. What I'm saying is
> that it would probably be appropriate to review them as they appear.

Is it #6915 you're talking about?

I'm not sure we're going to be able to properly review that before
the releases of 1.0.2 and 1.1.0.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Releases tomorrow

2018-08-13 Thread Kurt Roeckx
On Mon, Aug 13, 2018 at 02:00:47PM +0100, Matt Caswell wrote:
> Just a reminder that we are doing the 1.0.2p and 1.1.0i releases
> tomorrow so I will be freezing the repo later this afternoon. If you
> still have PRs to merge for the release please get them in asap!

Any plans for the -pre9?


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Fractional seconds, etc.

2018-08-14 Thread Kurt Roeckx
On Tue, Aug 14, 2018 at 12:16:25PM +, Salz, Rich wrote:
> I think we should revert https://github.com/openssl/openssl/pull/2668
> 
> The stricter RFC compliance turns out to impact many certs embedded in 
> devices.  Some estimates had thousands to millions.  It affects interop with 
> IAIK and Bouncy Castle.
> 
> I looked at the code, and tried to figure out how to just relax the 
> fractional second code, but it wasn’t obvious. There is also a testcase that 
> would need to be modified. And finally, it’s not clear that the seconds are 
> the only compatibility issue we would be introducing.
> 
> Unfortunately, this turns out to be a big breaking change, and doesn’t seem 
> right for a dot release.

This seems to have been done in both the 1.0.2 and 1.1.0 after the
release. Do you want to revert it in both branches, but keep it in
1.1.1? Or only revert it in 1.0.2?


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Late thoughts on the 1.1.1 release - are we fooling ourselves?

2018-08-17 Thread Kurt Roeckx
On Fri, Aug 17, 2018 at 01:55:13PM +0200, Richard Levitte wrote:
> Personally, I see this as a showstopper re a release on Tuesday

You mean a beta release?


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Is this still relevant to OpenSSL?

2018-08-21 Thread Kurt Roeckx
On Mon, Aug 20, 2018 at 04:03:13PM -0700, Paul Dale wrote:
> Abstract: This work provides a systematic analysis of primality testing under 
> adversarial conditions, where the numbers being tested for primality are not 
> generated randomly, but instead provided by a possibly malicious party
> 
> https://eprint.iacr.org/2018/749

We got an early copy of that paper. What that paper mostly says is
that we didn't properly document the amount of rounds required in
case you can't trust the input, the documentation has been
changed to make that more clear.

Related to that, since that paper we have increased the number of
Miller-Rabin rounds, but that work started before we saw that
paper.

As result of that paper I've started working on the Lucas prime
test, for which there is an open PR. I intend to create a
Bailie-PSW test after 1.1.1.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] OpenSSL version 1.1.1 pre release 9 published

2018-08-21 Thread Kurt Roeckx
On Tue, Aug 21, 2018 at 12:36:02PM +, OpenSSL wrote:
> 
>OpenSSL version 1.1.1 pre release 9 (beta)

I've uploaded that version to Debian unstable, so it should get
more testers now.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Speaking of broken master, have a look at Travis

2018-07-24 Thread Kurt Roeckx
On Tue, Jul 24, 2018 at 07:54:58PM +0200, Richard Levitte wrote:
> ...
> go test: FAILED (ServerNameExtensionServer-TLS1)
> go test: unexpected failure: local error 'read tcp4 
> 127.0.0.1:41729->127.0.0.1:60574: read: connection reset by peer', child 
> error 'signal: segmentation fault (core dumped)', stdout:

This is caused by https://github.com/openssl/openssl/pull/6378


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Release Criteria Update

2018-09-06 Thread Kurt Roeckx
On Tue, Sep 04, 2018 at 05:11:41PM +0100, Matt Caswell wrote:
> Current status of the 1.1.1 PRs/issues:

Since we did make a lot of changes, including things that
applications can run into, would it make sense to have an other
beta release?


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] coverity defect release criteria (Fwd: New Defects reported by Coverity Scan for openssl/openssl)

2018-09-10 Thread Kurt Roeckx
On Sun, Sep 09, 2018 at 11:44:33PM +0100, Matt Caswell wrote:
> 
> As far as the release criteria go we only count the ones shown in the
> Coverity tool. That's not to say we shouldn't fix issues in the tests as
> well (and actually I'd suggest we stop filtering out problems in the
> tests if anyone knows how to do that...perhaps Tim?).

You can change that in the project settings, where it splits the
paths into different groups.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] VOTE report: Push the release of 1.1.1 beta1 (pre3) forward one week

2018-03-10 Thread Kurt Roeckx
On Sat, Mar 10, 2018 at 11:45:46AM +0100, Richard Levitte wrote:
> Vote text:
> 
> NOTE: THREE DAY VOTE
> Why?  Because beta1 is currently scheduled to be released in three
> days.  A longer voting period would hold the release hostage in
> practice, and thereby force a push of the release date regardless of
> the vote result.

As explained by Rich on the OMC list, we can't have that. I assume
it's a 1 week vote. But the vote can be closed earlier.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] DRBGs, threads and locking

2018-03-14 Thread Kurt Roeckx
On Wed, Mar 14, 2018 at 12:49:46PM +, Salz, Rich wrote:
> So is having a high-quality, lockless (per-thread) CSPRNG good enough for 
> now?  Phrased like that, I think so.  We have enough other stuff to do.  So 
> +1 to Kurt's per-thread approach.

I think it's better than what we have in 1.1.0. And if we think we
can improve it, I suggest we improve it after 1.1.1.

So I think the discussion is both about speed and security.

>From what I understand from various things is that the random
number generate is now for some workloads at least a limiting
factor. Having it lockless and per thread is both the easiest
thing to do and gives the best performance.

When it comes to security, there seems to be a concern that from
the public data it might be possible to determine the internal
state, and that this might possibly have an effect on the security
of a different connection. But we have the same situation now in
1.1.0. And I'm still waiting for people to properly explain that
having it per SSL is better or not, there at least doesn't seem
to be an agreement on that part.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] DRBGs, threads and locking

2018-03-13 Thread Kurt Roeckx
So Tim has voted -1 on PR #5547 and wants us to discuss it here
and vote on it.

I don't know if it's clear to everybody what this is about. If
something is not clear, please ask. PR #5461 contains a
lot of documentation updates that is related to it, and it might
be useful to read it as background information. There are many
other related issues and pull request. I will try to make a basic
summary here.

The DRBGs is what we use to generate random numbers. They have the
possibility to chain, where 1 DRBG gets it's entropy from it's
parent. You can make long chains with this.

The current state in master is that you have 1 master DRBG that
gets it's entropy from the OS, and then 1 public and 1 private
DRBG that gets the entropy from the master. Then there is an DRBG
in the SSL struct that gets it's entropy from the public DRBG.

I have 2 problems with the current setup that I would like to
solve:
- On SSL_new() we create a new DRBG. That needs to get initialized
  and that requires getting entropy from somewhere, where that's
  currently the global public DRBG. This requires taking a lock.
- If we actually want to use the DRBG for everything related to
  that SSL connections to avoid having to lock a global DRBG
  everything that SSL code calls needs to be able to say with
  which DRBG it needs to generate random data. There was already 1
  PR related to this merged. PR #5510 is still open that deals at
  least with mot of it that I know about. I find that a very ugly
  hack and really don't see an easy way improve it.

My solution is to just have 1 master DRBG, and a public and
private DRBG per thread. The only lock that then is needed is when
the public or private DRBG needs to reseed. All the rest of the
code can stay just as it is, but we might want to change some
places to use the (thread local) private DRBG, which is what #4665
is about.

Some people seem to have a desire to have a separate the DRBGs per
SSL connection, at least for the public data. This is for cases
where from that data it would be possible to get the internal
state of the DRBG that is at least allegedly possible with the
DUAL_EC_DRBG. I believe this is mitigated somewhat by our mixing
in additional data when calling RAND_bytes() (or RAND_priv_bytes()),
but I'm not an expert in this and will leave this to the others to
comment on.

So the suggestion was to still have a per SSL public DRBG, but
then the problem is that that SSL object might have moved to a
different thread between creating and being used and so that the
parent DRBG might actually belong to a different thread. One
solution there is that we just take the current thread's public
DRBG as parent instead of the original threads public DRBG.


I hope I at least covered most of it.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Entropy seeding the DRBG

2018-04-07 Thread Kurt Roeckx
On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote:
> In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018 18:00:32 
> +0200, Kurt Roeckx <k...@roeckx.be> said:
> 
> kurt> On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> kurt> > > Can I suggest you try something like
> kurt> > > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
> kurt> > > get an idea? You would need to sample 1 variable and feed that into
> kurt> > > it.
> kurt> > 
> kurt> > And yeah, sure, especially if all it takes is to produce a stream of
> kurt> > bits from a source and feed that to the assessment program.  As long
> kurt> > as I don't have to port a C++11 program to VMS, 'cause unfortunately,
> kurt> > the existing C++ compiler hasn't had a real update for quite a while
> kurt> > :-/ (I'm sure that VSI is quite busy updating all they can, but they
> kurt> > haven't let anything out yet)
> kurt> 
> kurt> You only need to generate the bits on VMS, you can run the tool on
> kurt> some other machine.
> 
> Cool.
> 
> kurt> If you have such a program that collects the bits, I would like
> kurt> to review it. I would also like to test something like that over
> kurt> a range of machines it's expected to run on.
> 
> Errr  I have no idea what you're talking about.  I know of no
> other operating system that provides the system services VMS does, so
> I wonder how you expect to run the program gathering those data on
> anything other than VMS.

I mean multiple VMS machines on different processors / hardware.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Kurt Roeckx
On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> In message <20180407154649.ga12...@roeckx.be> on Sat, 7 Apr 2018 17:46:50 
> +0200, Kurt Roeckx <k...@roeckx.be> said:
> 
> kurt> | For case 2 above, the timestamp must be trusted. A trusted
> kurt> | timestamp is generated and signed by an entity that is trusted
> kurt> | to provide accurate time information.
> kurt> 
> kurt> Case 1 requires an approved random bit generator, which we don't
> kurt> have by default.
> kurt> 
> kurt> Case 2 requires the timestamp to be trusted. I think that applies
> kurt> to case 4 too. This is also something we can't do by default.
> 
> I'm not sure what you mean with "trusted"...

It's right there in the quoted text, it needs to be signed.

But I wonder how that it supposed to really work. If you want to
avoid a replay attack, does that mean you need to use a nonce? Do
we bootstrap problem?

> kurt> I think case 3 requires us keep a counter even after restarting
> kurt> the application, which seems unlikely that we will implement it.
> kurt> 
> kurt> So by default we can't do any of them. But you can argue that we
> kurt> can do case 1, 2 and 4 close enough. Case 1 is what we do now.
> 
> H...  case 4 shouldn't pose too much problems unless you restart
> the application more than once every second or so (for a 1 second
> resolution).  On VMS, the system time is kept with 100 nanosecond
> granularity...  this doesn't mean that it's actually updated every 100
> nanosecond, but the possibility is there when VMS runs on fast enough
> hardware (a VAX is decidedly not in that range, Alpha has a minimum
> update rate of 1ms, Itaniums are faster than most Alphas...).  Either
> way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
> counter to match the 128 bit nonce requirement, do I get that right?

What is not clear to me is that all DRBGs (the 1+2N) need to have
a unique nonce or not. The 3 first are all most likely to be
instantiated very close to each other. It might be that the
requirement is the nonce for all 3 is different. If you combine
this with a counter (case 4), it's easy to do this on a per
process basis, even if the time is only updated once per second.

But maybe the requirement can be over multiple processes? I really
don't know enough about this.

> kurt> I think we can do case 2 with something like gettimeofday() or
> kurt> clock_gettime() which I think provide plenty of resolution
> kurt> that it's unlikely to repeat.
> kurt> 
> kurt> You can combine that with a counter to get case 4 if you really
> kurt> wanted.
> kurt> 
> kurt> All you have to do is implement a get_nonce() function and set
> kurt> it by default. You can keep the behaviour that if no get_nonce
> kurt> function is set that it increases the entropy requirement.
> 
> Aha ok!  Yeahok, I see, so if I implement a rand_drbg_get_nonce in
> rand_vms.c, we're basically set...  but that means we need to
> implement a generic one as well, no?

It might be a little strange that the default is different on
different platforms, but I don't see why that should be a problem.
But having a generic one is probably more useful to a VMS specific
one.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Kurt Roeckx
On Sat, Apr 07, 2018 at 04:48:51PM +, Salz, Rich wrote:
> >Like I said in the post I just made, I see zero problems with having
> that requirement on systems that can support it.  I don't see why we
> must lower the bar for *everyone* just because we currently need to do
> so for VMS
>   
> Because
>   - It is not clear we need to do so

That we need to do what?

>   - We are not required to do FIPS level DRBG/CSPRNG this release

It's not because we don't have a requirement that it can be
validated, that we should only implement it half. There are
reasons for those requirements, and they are valid even if you
don't validate it.

There are things we will not be able to do by default, because the
OS does not provide what is needed. But I think there is at least
enough code in there that you can write something so that the DRBG
can be validated.

>   - It is probably not appropriate in an API/ABI compatible release
>   - It is not appropriate for a "silent change"

I'm not sure what you're talking about with the last 2 items. What
changes are you talking about?

What I think might come more as something that breaks things is
that we now periodically reseed. It's not good enough anymore to
have /dev/urandom available at the start and before you chroot, it
now also needs to be available after you chroot. Our use of
getrandom() when available avoids this a little. But glibc in
Debian stable is only at glibc 2.24 while 2.25 is needed. I think
we should consider having support for the syscall ourself. We
should probably also add support for such functions on *BSD.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-07 Thread Kurt Roeckx
On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
> > Because
> > - It is not clear we need to do so
> 
> >That we need to do what?
> 
> Do FIPS compliant random numbers in this release.

We will never have that in any release by default, like I already
stated a few times.

> Everything is a trade-off.  Please explain why you want AES256-CTR with a 
> nonce, and why AES128-CTR with personalization (and/or a DF) is not 
> sufficient.

RAND_DRBG_set() takes 2 parameters: type and flags.

Type can be:
- NID_aes_128_ctr
- NID_aes_192_ctr
- NID_aes_256_ctr

The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
is required. When not using a DF the nonce is not used.

We always use a personalization string.

The requirements for not using a DF means that you need to use
"full entropy", which is even more strict then when using a DF.
Since we don't have a "full entropy" source, we can generate it
ourself, but it would require the double amount of entropy, so 512
bit. We have no code currently to do this, but there is an open
issue about it.

There are other reasons we want to use the DF by default:
- We might have entropy sources that provide less than 8 bit of
  entropy per byte.
- We still want to support RAND_add()

The reason for the 256 bit version is that there are people that
want more than the 128 bit security level. In fact, our default
cipher order has aes-256 first. And I still read current
recommendations to use aes-256. I also read that the aes_128_ctr
DRBG might not even provide the 128 bit level, but something
much lower.


> > But I think there is at least
> enough code in there that you can write something so that the DRBG
> can be validated.
>
> But that wasn't a goal.  It *is* a goal of our next release.

So because it's not a goal to provide SM2/SM3/SM4, we don't care
that it's actually implemented properly? It's enough to just have
that name, and might do something totally different?

You also argue that because we agreed to TLS 1.3, that AES must
also be properly implemented? Doesn't it also require a proper
RNG? Or can we just call rand()?

> > - It is probably not appropriate in an API/ABI compatible 
> release
> > - It is not appropriate for a "silent change"
> 
> I'm not sure what you're talking about with the last 2 items. What
> changes are you talking about?
> 
> The fact that 384 bits of seed are needed, when before it was 128.

The previous release was 256, not 128.

> >getrandom() when available avoids this a little. But glibc in
> Debian stable is only at glibc 2.24 while 2.25 is needed. I think
> we should consider having support for the syscall ourself. We
> should probably also add support for such functions on *BSD.
>   
> So this is now a break change for debian stable?

Stable has 1.1.0 (and 1.0.2) and will most likely stay on 1.1.0.
But people will want to use TLS 1.3, so I will at least provide it
in backports. And unless we add support for the syscall, it will
probably come with some warning.

>  All the more reason to revert it.

You mean remove the whole DRBG? Or the reseeding?

(The 384 vs 256 really doesn't have any effect on /dev/urandom not
being in a chroot.)

> In going from 1.1.0 to 1.1.1, breaking platforms that used to work is just 
> plain wrong.

So then I suggest we support the syscalls on all platforms that
provide it.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-08 Thread Kurt Roeckx
On Sun, Apr 08, 2018 at 10:31:58AM +0200, Richard Levitte wrote:
> In message <20180408080942.gb3...@roeckx.be> on Sun, 8 Apr 2018 10:09:42 
> +0200, Kurt Roeckx <k...@roeckx.be> said:
> 
> kurt> On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote:
> kurt> > In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 
> 21:02:51 +0200, Kurt Roeckx <k...@roeckx.be> said:
> kurt> > 
> kurt> > kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> kurt> > kurt> > H...  case 4 shouldn't pose too much problems unless you 
> restart
> kurt> > kurt> > the application more than once every second or so (for a 1 
> second
> kurt> > kurt> > resolution).  On VMS, the system time is kept with 100 
> nanosecond
> kurt> > kurt> > granularity...  this doesn't mean that it's actually updated 
> every 100
> kurt> > kurt> > nanosecond, but the possibility is there when VMS runs on 
> fast enough
> kurt> > kurt> > hardware (a VAX is decidedly not in that range, Alpha has a 
> minimum
> kurt> > kurt> > update rate of 1ms, Itaniums are faster than most Alphas...). 
>  Either
> kurt> > kurt> > way, the timestamp is 64 bits, it seems that then, we'd add a 
> 64-bit
> kurt> > kurt> > counter to match the 128 bit nonce requirement, do I get that 
> right?
> kurt> > kurt> 
> kurt> > kurt> The requirement is not to have it 128 bit. Just that it doesn't
> kurt> > kurt> repeat as often as a 128 random number. You're most likely not
> kurt> > kurt> going to instantiate it 2^64 times. As long as the combination 
> is
> kurt> > kurt> unique, it should be fine.
> kurt> > 
> kurt> > "The requirements" depend on where you look.  Looking at the code, or
> kurt> > more specifically drbg_ctr_init in drbg_ctr.c, about line 421, I see
> kurt> > this:
> kurt> > 
> kurt> > drbg->min_noncelen = drbg->min_entropylen / 2;
> kurt> > 
> kurt> > So the DRBG CTR code currently requires 128 bits minimum by default,
> kurt> > unconditionally.
> kurt> 
> kurt> The standard does not require this 128 bit. This 128 bit is only
> kurt> required for the random value. The example even has a nonce of 32
> kurt> bit.
> 
> So then maybe the code in drbg_ctr_init() shouldn't set such a high
> minimum when drbg->get_nonce is defined?  That, or RAND_DRBG_instantiate()
> shouldn't try to check against drbg->min_noncelen, i.e. the latter
> should only be used when drbg->get_nonce is undefined.

Yes, after what I all said previously, it's clear the code could
use improvements. I think at least Matthias and I assumed the code
about the minimum size was correct and that there was a minimum
requirement of 128 bit.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-08 Thread Kurt Roeckx
On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote:
> In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 21:02:51 
> +0200, Kurt Roeckx <k...@roeckx.be> said:
> 
> kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> kurt> > H...  case 4 shouldn't pose too much problems unless you restart
> kurt> > the application more than once every second or so (for a 1 second
> kurt> > resolution).  On VMS, the system time is kept with 100 nanosecond
> kurt> > granularity...  this doesn't mean that it's actually updated every 100
> kurt> > nanosecond, but the possibility is there when VMS runs on fast enough
> kurt> > hardware (a VAX is decidedly not in that range, Alpha has a minimum
> kurt> > update rate of 1ms, Itaniums are faster than most Alphas...).  Either
> kurt> > way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
> kurt> > counter to match the 128 bit nonce requirement, do I get that right?
> kurt> 
> kurt> The requirement is not to have it 128 bit. Just that it doesn't
> kurt> repeat as often as a 128 random number. You're most likely not
> kurt> going to instantiate it 2^64 times. As long as the combination is
> kurt> unique, it should be fine.
> 
> "The requirements" depend on where you look.  Looking at the code, or
> more specifically drbg_ctr_init in drbg_ctr.c, about line 421, I see
> this:
> 
> drbg->min_noncelen = drbg->min_entropylen / 2;
> 
> So the DRBG CTR code currently requires 128 bits minimum by default,
> unconditionally.

The standard does not require this 128 bit. This 128 bit is only
required for the random value. The example even has a nonce of 32
bit.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-08 Thread Kurt Roeckx
On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
> On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
> > > Because
> > >   - It is not clear we need to do so
> > 
> > >That we need to do what?
> > 
> > Do FIPS compliant random numbers in this release.
> 
> We will never have that in any release by default, like I already
> stated a few times.
> 
> > Everything is a trade-off.  Please explain why you want AES256-CTR with a 
> > nonce, and why AES128-CTR with personalization (and/or a DF) is not 
> > sufficient.
> 
> RAND_DRBG_set() takes 2 parameters: type and flags.
> 
> Type can be:
> - NID_aes_128_ctr
> - NID_aes_192_ctr
> - NID_aes_256_ctr
> 
> The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
> is required. When not using a DF the nonce is not used.
> 
> We always use a personalization string.
> 
> The requirements for not using a DF means that you need to use
> "full entropy", which is even more strict then when using a DF.
> Since we don't have a "full entropy" source, we can generate it
> ourself, but it would require the double amount of entropy, so 512
> bit. We have no code currently to do this, but there is an open
> issue about it.

This is actually wrong. When not using a DF, the seed length = 384
for NID_aes_256_ctr. So we would need 768 bits of entropy if we
don't have access to full entropy.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-08 Thread Kurt Roeckx
On Sun, Apr 08, 2018 at 08:29:18PM +, Dr. Matthias St. Pierre wrote:
> Just for completeness sake: The entropy requirement is 256 and *not* 384 if a 
> derivation function is used.

But one way of implementing the nonce when a DF is not used, is to
also have 384 bit in that case, which is our current
implementation. If someone writes a default get_nonce function it
can be reduced to 256.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

2018-04-08 Thread Kurt Roeckx
On Sun, Apr 08, 2018 at 07:15:16PM +0200, Richard Levitte wrote:
> 
> 
> Kurt Roeckx <k...@roeckx.be> skrev: (8 april 2018 17:36:27 CEST)
> >On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
> >> On Sat, Apr 07, 2018 at 05:55:14PM +, Salz, Rich wrote:
> >> > > Because
> >> > >- It is not clear we need to do so
> >> > 
> >> > >That we need to do what?
> >> > 
> >> > Do FIPS compliant random numbers in this release.
> >> 
> >> We will never have that in any release by default, like I already
> >> stated a few times.
> >> 
> >> > Everything is a trade-off.  Please explain why you want AES256-CTR
> >with a nonce, and why AES128-CTR with personalization (and/or a DF) is
> >not sufficient.
> >> 
> >> RAND_DRBG_set() takes 2 parameters: type and flags.
> >> 
> >> Type can be:
> >> - NID_aes_128_ctr
> >> - NID_aes_192_ctr
> >> - NID_aes_256_ctr
> >> 
> >> The only flag is RAND_DRBG_FLAG_CTR_NO_DF. When using a DF a nonce
> >> is required. When not using a DF the nonce is not used.
> >> 
> >> We always use a personalization string.
> >> 
> >> The requirements for not using a DF means that you need to use
> >> "full entropy", which is even more strict then when using a DF.
> >> Since we don't have a "full entropy" source, we can generate it
> >> ourself, but it would require the double amount of entropy, so 512
> >> bit. We have no code currently to do this, but there is an open
> >> issue about it.
> >
> >This is actually wrong. When not using a DF, the seed length = 384
> >for NID_aes_256_ctr. So we would need 768 bits of entropy if we
> >don't have access to full entropy.
> 
> Wait what? This sounds nuts... Can you refer to something that backs your 
> claim? 

The 384 comes straight out of SP800-90A, see the table 10.2.1.
It's also in the code where we do:
drbg->seedlen = keylen + 16;
[...]
if ((drbg->flags & RAND_DRBG_FLAG_CTR_NO_DF) == 0) {
[...]
} else {
drbg->min_entropylen = drbg->seedlen;

(With keylen == 32)

You'll also see that when not using a DF "full entropy" is needed,
when using a DF it's not required.

A DRBG can only generate "full entropy" for the first security
strength / 2 bits it generates after a reseed. This is at least
covered in SP800-90C 10.4, but there are other places that mention
this too. So you need to pull the double amount of entropy from
your entropy source if it doesn't provide full entropy. This also
requires to use of prediction resistance.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Entropy seeding the DRBG

2018-04-09 Thread Kurt Roeckx
On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote:
> kurt> I wonder if it's useful to have a thread of VMS that collects
> kurt> such bits all the time, like the kernel is doing.
> 
> I was pondering something like that, and it does make sense.  That, or
> creating a generic device driver (RND0:) that works a bit like the
> random driver on Linux, or perhaps the one from OpenBSD...

So one problem with OpenSSL doing this is that it's probably going
to take a while (in the order of seconds to minutes) before it's
ready, and I think you want to avoid that each time an application
using openssl starts. So a system service would be much better.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Entropy seeding the DRBG

2018-04-07 Thread Kurt Roeckx
On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> > Can I suggest you try something like
> > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
> > get an idea? You would need to sample 1 variable and feed that into
> > it.
> 
> And yeah, sure, especially if all it takes is to produce a stream of
> bits from a source and feed that to the assessment program.  As long
> as I don't have to port a C++11 program to VMS, 'cause unfortunately,
> the existing C++ compiler hasn't had a real update for quite a while
> :-/ (I'm sure that VSI is quite busy updating all they can, but they
> haven't let anything out yet)

You only need to generate the bits on VMS, you can run the tool on
some other machine.

If you have such a program that collects the bits, I would like to
review it. I would also like to test something like that over a
range of machines it's expected to run on.

I wonder if it's useful to have a thread of VMS that collects such
bits all the time, like the kernel is doing.

I'm going to guess that the 4 bit you count now is an overestimate.
And I would like to be very conservative in estimating something
like that, and even divide what the tool returns by 10.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-14 Thread Kurt Roeckx
On Sat, Apr 14, 2018 at 09:54:41PM +0200, Richard Levitte wrote:
> Yes, I agree that the TLSProxy tests aren't the most important in this
> regard.  Also note that this part was a side note.

Can you then find examples of what a normal user of the library
might be expected to do that fails?

I know some other libraries have tests to see if version
negiotation works properly. I expect those tests to fail, but I
don't see this as a problem because the tests don't know about
TLSv1.3 yet, and the library itself and it's users will work
without problems.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-14 Thread Kurt Roeckx
On Sat, Apr 14, 2018 at 09:32:31PM +0200, Richard Levitte wrote:
> 
> a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests
>that are meant to fail (i.e. if the individual tests fail, the
>recipe is successful).  When run against 1.1.1 libraries, the
>recipe fails, i.e. the injection of double hellos didn't get the
>communication to fail, or so it seems...

This seems to be a test that is very aware of the protocol, and
what should fail and what shouldn't. If you introduce a new
protocol, the things it check might need to be updated. This is
not something a normal application will be doing, so I don't see
this as a problem.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Constant time by default

2018-04-17 Thread Kurt Roeckx
On Mon, Apr 16, 2018 at 06:06:33PM +0100, Matt Caswell wrote:
> 
> As I say in the PR (marked as WIP) I am seeking feedback as to whether
> this is something we should pursue now (i.e. for 1.1.1) or later (post
> 1.1.1) or not at all.

A related question I have is, do we consider this security issues,
and does that mean we should backport those changes?


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-18 Thread Kurt Roeckx
On Wed, Apr 18, 2018 at 11:05:05AM -0400, Viktor Dukhovni wrote:
> 
> What I can blame them for is being counter-productively pedantic. Forget the 
> RFC language, does what they're doing make sense and improve security or is 
> it just a pointless downgrade justified by RFC text lawyering?

I'm not sure you actually get downgraded? I get TLS 1.2 in all
cases. I think they still speak a different draft version. If it's
boringssl, I think they do 22 and 23 in the last release and 26
(like we) in their current master version.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

2018-04-15 Thread Kurt Roeckx
On Sun, Apr 15, 2018 at 07:38:48AM +0200, Richard Levitte wrote:
> In message  on Sat, 14 Apr 
> 2018 21:13:47 +, "Salz, Rich"  said:
> 
> rsalz> We have *no* data points, except our tests, that anything fails to 
> work.
> rsalz> In fact, we are increasingly collecting data that shows everything is 
> just fine.
> 
> Errr, are we?  Please inform me, because I cannot remember having seen
> tests that specifically targets the case of programs built with 1.1.0
> that get implicitly relinked with 1.1.1 libraries (that's what you
> call "going forward", isn't it?), or data collection for that matter.
> I may have missed something, but I am interested.

In Debian we've done a rebuild test of all source packages that link
to 1.1.0 to build against pre2 instead, and as far as I know only 1
package was found to fail because of that: #5637

This is of course slightly different than just upgrading the
library since it can pick up new header files, but I think this is
close enough. It also only covers those packages that have a test
suite.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Problems with waiting for specific person to merge

2018-04-19 Thread Kurt Roeckx
On Thu, Apr 19, 2018 at 09:58:26AM +0200, Richard Levitte wrote:
> When someone with write access to the main repo makes a PR and it gets
> approved, we usually wait for the person to do the final merge.

This is also what we agreed to do a long time ago, including that
for PRs of a non-commiter, it's the the first commiter that approves
that is the one to merge it.

I really have no problem that someone else merges my pull
requests.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)

2018-04-20 Thread Kurt Roeckx
On Thu, Apr 19, 2018 at 07:16:04PM -0400, Viktor Dukhovni wrote:
> 
>   * Something else?

We could call for testing what really happens on -users? I could
also send one to debian-devel-announce, we already have pre4 in
experimental.

Maybe we can convert the blog post into a wiki, update it to the
current status, and point people to that.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Entropy seeding the DRBG

2018-04-23 Thread Kurt Roeckx
On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> In the mean time, I've spent a few days going through the docs on all
> kinds of data that you can get out from the VMS kernel, most notably
> through a system service called sys$getrmi()...  there's a gazillion
> data points, a treasure trove for anyone that's into statistics.  And
> I intend to spend some time trying to estimate what kind of entropy I
> can get out of them...
> 
> ... and that's where Kurt came in:
> 
> > Can I suggest you try something like
> > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
> > get an idea? You would need to sample 1 variable and feed that into
> > it.
> 
> And yeah, sure, especially if all it takes is to produce a stream of
> bits from a source and feed that to the assessment program.  As long
> as I don't have to port a C++11 program to VMS, 'cause unfortunately,
> the existing C++ compiler hasn't had a real update for quite a while
> :-/ (I'm sure that VSI is quite busy updating all they can, but they
> haven't let anything out yet)
> 
> But either way, creating a better entropy gatherer is the longer term
> goal.  I hope I get that part done before the release.

Any update on this?


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-19 Thread Kurt Roeckx
On Thu, Apr 19, 2018 at 02:02:53PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni  
> > wrote:
> > 
> > There is no "the name that is being verified".  The Postfix SMTP client 
> > accepts multiple (configurable as a set) names for the peer endpoint.  This 
> > may be the next-hop domain or the MX hostname, or a sub-domain wildcard, or 
> > some fixed hardcoded-name, or a mixture of these...
> 
> Furthermore, with SMTP servers we can't be sure whether the peer even 
> tolerates SNI, it may decide that it has no certificate exactly matching the 
> client's guess, and hang up, even though the client would be happy with the 
> default certificate.
> 
> I'm reluctant to start sending SNI in configurations that work fine without 
> SNI, and could well break when it is introduced.  So if you're at all in 
> touch with the Gmail folks, please work with them to undo the ratchet in 
> question, at least SMTP MUST NOT suddenly stop yielding the expected default 
> certificate for lack of SNI.

I think there might be some disagreement on how to go forward with
having proper TLS in SMTP. I think Google might want to go with
how it works for https, and so have certificates issued by a CA
for hostname you try to connect to. I think you would like to use
DANE instead. But I don't see DNSSEC or DANE getting wide adoption.

I currently see 4 type of connections for my outgoing mail in my
postfix log:
- Verified TLS connection: self-signed DANE
- Verified TLS connection: DANE but with a valid certificate
- Untrusted TLS connection: People who have a valid certificate
  for the hostname I connect to
- Anonymous TLS: Using an anoymous cipher, yet having a valid
  certificate

This is of course a very limited amount, only for what I send,
but I think TLS for SMTP is already in a much better state now.
I think in the end we should just enforce proper certificates.

It would be nice that all those that do have a proper certificate
are actually marked as "Verified", there really is no reason
to say they are Untrusted.

It would also be nice that if the client sends an SNI and you have
a certificate for it that it wouldn't select an anonymous cipher.
But then postfix is probably the only one that does anonymous
ciphers, and if it's not sending SNI this will not change much.

But I don't agree to Google's use of SNI, saying that if it
supports TLS 1.3 that it must be modern software that should send
an SNI. The library (OpenSSL) will support it, but that doesn't
mean that application will set it, or that upgrading OpenSSL will
suddenly make the appliation set it. I also don't see a relation
between not sending SNI and not checking the certificate, you can
perfectly write code that does not send an SNI but does proplery
validate the certificate.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

2018-04-19 Thread Kurt Roeckx
On Thu, Apr 19, 2018 at 09:15:19PM +0200, Kurt Roeckx wrote:
> 
> It would also be nice that if the client sends an SNI and you have
> a certificate for it that it wouldn't select an anonymous cipher.
> But then postfix is probably the only one that does anonymous
> ciphers, and if it's not sending SNI this will not change much.

An alternative is that if you think the certificate should be
trusted by the peer you don't select an anonymous cipher.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)

2018-04-19 Thread Kurt Roeckx
On Thu, Apr 19, 2018 at 07:16:04PM -0400, Viktor Dukhovni wrote:
> 
> But not all the friction can be eliminated, and likely not
> all providers can be persuaded to be more accommodating.
> Which leaves us with some difficult judgement calls:
> 
>   * Restrict TLS 1.3 support to just applications compiled
> against 1.1.1?  A weak signal, but likely correlates at
> least somewhat with the application being ready.

Applications get rebuild for all sort of reasons, I don't actually
see this as a good signal at all.

>   * Determine whether the application is likely to be compatible
> at runtime by looking at the provided configuration.  Is SNI
> enabled?  Is the certificate chain weird enough to break with
> TLS 1.3.  Has the application turned off critical algorithms?
> 
>   * Do nothing, let the applications adapt or stick with older
> libraries?

I'm for keeping this as they are now. After the release some
things might break. Applications will adapt.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Entropy seeding the DRBG

2018-04-03 Thread Kurt Roeckx
On Tue, Apr 03, 2018 at 12:52:50PM +, Salz, Rich wrote:
> I had not realized that we just increased the “entropy” requirements by 50%, 
> from 256 to 384. The original DRBG submission that I did only required 128 
> bits.  I think that is wrong, and I think the PR that did it (#5503) should 
> be reverted.
> 
> I am concerned that we are trying to meet requirements that we really don’t 
> have.  The original code was a huge improvement.
> 
> Requiring 384 bits of random seed is silly.  I think it is ridiculous.  One 
> way or another we HAVE to fix that before the release.

Please note that that 50% extra is only used for instantiating the
DRBG. On reseed we it only uses 256 bits.

There is an alternative to that 50% extra, but it's not making
sense to me.

The 1.1.0 version also used 256 bit.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Next release is beta1

2018-03-04 Thread Kurt Roeckx
On Fri, Mar 02, 2018 at 11:09:30AM +, Matt Caswell wrote:
> Just a reminder, in case anyone missed it, that our next planned release
> on 13th March is beta1. This means we will be calling a feature freeze
> for 1.1.1 and we will create the new branch. If you've got any
> outstanding feature PRs that you want in for 1.1.1 - then now is the
> time to get them finished off!

The other option is that we delay going to beta, but then people
would need to speak up now about what they would like to see
happen before going to beta.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Next release is beta1

2018-03-04 Thread Kurt Roeckx
On Sun, Mar 04, 2018 at 02:44:01PM +, Salz, Rich wrote:
> I also intend to merge the config file .include PR (5351), and I want us to 
> decide about 4848.

I have to agree that I want to resolv 4848 (reading config file to
select things like supported ciphers.)

An other important change is related to cipher selection and TLS
1.3, not sure what the status there is.

There is also still work going on related to the DRBG API.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] dropping out

2018-10-12 Thread Kurt Roeckx
On Fri, Oct 12, 2018 at 02:01:42PM +0200, Andy Polyakov wrote:
> Another contributing factor is lack of opportunities to pursue
> so to say "fundamental" goals, formal validation of assembly code being
> one example.

Formal validation of the assembly code is something I would
actually like to see, and even talked with some people about it.
But I don't have the time to actually get this done.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Current priorities

2018-10-16 Thread Kurt Roeckx
On Tue, Sep 18, 2018 at 08:06:12PM +0200, Kurt Roeckx wrote:
> The open PRs were around 100 when 1.1.0 was released, and have
> been around 120 for a very long time, but the last few months it has
> grown to around 150. I guess we have some that are waiting because
> they are new features that didn't go in 1.1.1. But I would like to
> get the number of open PRs to around 100, but even lower is of
> course even better.

We currently at 176 open PR, that's 25 more open PRs 1 month
later.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Random devices in chroot environments revisited

2018-10-30 Thread Kurt Roeckx
On Tue, Oct 30, 2018 at 07:23:52PM +, Dr. Matthias St. Pierre wrote:
> Hi,
> 
> I'd like to recall that the following issue
> 
> #7419 - RAND_keep_random_devices_open not working
> 
> still needs to be fixed until 1.1.1a and that currently there are two
> alternative approaches for doing it:
> 
> #7429 - Conditionally open random devices on initialization
> #7437 - rand_unix.c: open random devices on first use only 
> 
> A short recall of the background story: In pull request
> 
> #6432 - Keep /dev/random open for seeding
> 
> a regression was fixed that affected applications in chroot environments.
> It compensated the fact that the new OpenSSL CSPRNG now reseeds
> periodically, which the previous one didn't.
> 
> The solution was to open all random devices early and keep them
> open.  An API call (RAND_keep_random_devices_open()) was added
> for the application to opt-out from this behaviour.
> 
> In issue #7419 it was reported that this opt-out did not work as expected.
> 
> *  Pull request #7429 fixes the opt-out issue but remains along the lines of
> the initial solution #7432. This approach has the side effect that the
> random devices are always opened, even if they are never used
> (for example, because getrandom() is available). Even more, if the
> application forks and execs, these handles will be left open and unused
> in the child process.
> 
> An application which does not want this behavior, could explicitly 
> opt-out,
> but this would require a recompilation, which is somewhat contrary to
> the assumptions of the initial chroot problem.
> 
> *  Pull request #7429 works without explicit opt-out, because it opens the

#7437 I guess

> random devices on first use only (and then keeps them open, unless
> the opt-out was called). The advantage of this approach: If getrandom()
> is available and working, the opening will never happen.
> 
> The lazy opening does not add a regression for applications compiled
> against 1.1.0, because the old SSLEAY CSPRNG used to be initialized 
> on first use, too. So also with 1.1.0 it was necessary to initialize the
> CSPRNG properly before chrooting (unless the random device was
> mounted into the chroot jail).
> 
> Your thoughts?

I prefer the option where it doesn't get opened if getrandom() is
avialable.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] Minimum C version

2018-10-07 Thread Kurt Roeckx
Hi,

We're currently still targetting C89/C90 + long long, yet use
various features of C99 and even some C11 when it's available.

C99 is now almost 20 years old, can we please move to at least
that?


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Minimum C version

2018-10-07 Thread Kurt Roeckx
On Sun, Oct 07, 2018 at 02:01:36PM +0100, David Woodhouse wrote:
> Unfortunately Microsoft still does not support C99, I believe. Or did that 
> get fixed eventually, in a version that can reasonably be required?

That is a very good point, and they never intend to fix that.

So would that mean we say that VC will be unsupported? Or that we
should make it so that it can be build using C++?


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Current status of our release criteria

2018-09-03 Thread Kurt Roeckx
On Mon, Sep 03, 2018 at 05:54:52PM +0100, Matt Caswell wrote:
> 
> #7014: TLSv1.2 SNI hostname works in 1.1.0h, not in 1.1.1 master (as of 18
> 
> Ben has asked for input from the OMC on this one

So SSL_get_servername() was not documented in 1.1.0, but did exist
in it. It's currently documented as:

   SSL_get_servername() returns a servername extension value
   of the specified type if provided in the Client Hello or NULL.

It's clearly a function intended to be used to select which
certificate should be used, during the negotation. But it seems
that someone uses it after the negotation, or the SNI callback,
and now gets NULL in case SNI was sent but not used.

It at least looks like a misuse of the API, but the documentation
does not say when you can call this function, unlike the
SSL_CTX_set_client_hello_cb() documentation.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Current status of our release criteria

2018-09-03 Thread Kurt Roeckx
On Mon, Sep 03, 2018 at 05:54:52PM +0100, Matt Caswell wrote:
> 
> #7058: Process handshake messages after we've send a shutdown
> 
> Awaiting updates from @kroeckx...Kurt will you able to do that soon? Or
> alternatively (if you prefer) I can take this one over.

I was waiting for your feedback, but feel free to take it over.
I'm happy to review such changes.

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Release strategy updates & other policies

2018-09-26 Thread Kurt Roeckx
On Tue, Sep 25, 2018 at 08:13:53PM +1000, Tim Hudson wrote:
> On Tue, Sep 25, 2018 at 8:07 PM Matt Caswell  wrote:
> 
> > On 25/09/18 10:58, Tim Hudson wrote:
> > > On Tue, Sep 25, 2018 at 7:23 PM Richard Levitte  > > > wrote:
> > >
> > > So what you suggest (and what I'm leaning toward) means that we will
> > > change our habits.
> > >
> > >
> > > Adoption of semantic versioning will indeed require us to change our
> > > habits in a number of areas - that is the point of having a single clear
> > > definition of what our version numbers mean.
> > >
> > > I also do think we need to document a few things like what we mean by
> > > bug fix compared to a feature update as there are items which we could
> > > argue could either be a PATCH or a MINOR update depending on how we
> > > describe such things.
> >
> > Sometimes we need to add a function in order to fix a bug. How should
> > this be handled? e.g. there are 60 functions defined in
> > util/libcrypto.num in the current 1.1.0i release that weren't there in
> > the original 1.1.0 release.
> >
> 
> 
> In semantic versioning those are MINOR releases. The API has changed in a
> backward compatible manner.
> They cannot be called PATCH releases - those are only for internal changes
> that fix incorrect behaviour.
> If you change the API you are either doing a MINOR or a MAJOR release.

We might need to add this to multiple branches at the same time.

Assume that we have a 2.0.5 and 2.1.2 version. And in both
versions we need to add that a new function, what should the
new versions be? My understanding is that you can't actually do
it.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

2019-01-22 Thread Kurt Roeckx
On Tue, Jan 22, 2019 at 02:48:26PM -0500, Viktor Dukhovni wrote:
> As for applications mishandling "SSL_CB_HANDSHAKE_START", not quite sure
> what to do there, but perhaps we could define a new even for keyUpdates
> that does not mislead applications into assuming a new "handshake".

I think calling anything a handshake that is not a handshake
should either be removed or renamed. KeyUpdate is not a handshake.
I'm not sure what we do in case of a session ticket, but it also
shouldn't send such events, but other events are probably useful
in that case.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] Vote to update the security policy

2018-12-06 Thread Kurt Roeckx
On Thu, Nov 29, 2018 at 03:34:29PM +, Mark J Cox wrote:
> Changes to policies require an OMC vote which I've called to approve an
> update to the security policy.  This was as discussed at the face to face
> and the details and diff are at https://github.com/openssl/web/pull/96
> 
> 
> topic: Update security policy as per https://github.com/openssl/web/pull/96

This vote failed with 4 votes against and 3 people not voting.

The intend of voting against is to work on the wording and then
call a new vote.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


[openssl-project] Current priorities

2018-09-18 Thread Kurt Roeckx
Hi,

Now that 1.1.1 is released, and before everybody starts to work on
new features, I would like to suggest that we work on reducing the
number of open pull requests and issues.

Fixing issues that are regressions in the 1.1.1 version is
something we really should be doing, and I think that should
currently be our top priority. We should probably also do a new
release after a month or something.

The open PRs were around 100 when 1.1.0 was released, and have
been around 120 for a very long time, but the last few months it has
grown to around 150. I guess we have some that are waiting because
they are new features that didn't go in 1.1.1. But I would like to
get the number of open PRs to around 100, but even lower is of
course even better.

I guess the open issues are also also growing, but I don't have
any numbers for that.


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] inline functions

2019-01-27 Thread Kurt Roeckx
On Sun, Jan 27, 2019 at 08:33:06PM +1000, Tim Hudson wrote:
> From https://github.com/openssl/openssl/pull/7721
> 
> Tim - I think inline functions in public header files simply shouldn't be
> present.
> Matt - I agree
> Richard - I'm ambivalent... in the case of stack and lhash, the generated
> functions we made static inline expressly to get better C type safety, and
> to get away from the mkstack.pl horror.

In general I have to agree that it's not a good thing to do,
specially in cases where it calls other functions. We went away
from making them just defines into functions, but they should
instead be functions in the library, at least for external users
of the library.


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

2019-02-06 Thread Kurt Roeckx
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

2019-01-29 Thread Kurt Roeckx
On Tue, Jan 29, 2019 at 01:27:24PM -0600, David Benjamin wrote:
> I think one clear conclusion from this incident is that this sort of
> low-level API should be avoided, or people will use them in finicky ways
> that break unexpectedly when you change things. Better defer such
> mechanisms to when concrete use cases come up, and then implement direct
> APIs for those use cases, like SSL_OP_NO_RENEGOTIATION.

I have to agree to that.


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

2019-01-29 Thread Kurt Roeckx
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)."

This will only cover the key update currently? Does that come with
some parameter telling which kind of handshake is happening? If
not, is it more useful to just say that a key update is happening?


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


Re: [openssl-project] [TLS] Yet more TLS 1.3 deployment updates

2019-01-28 Thread Kurt Roeckx
On Mon, Jan 28, 2019 at 03:38:50PM +, Matt Caswell wrote:
> 
> 
> On 24/01/2019 18:12, Sam Roberts wrote:
> > The other changes that TLS1.3 requires, multiple session tickets, a
> > few new APIs to replace some of the SSL_renegotiate use-cases, etc.,
> > all are pretty routine. We could get TLS1.3 support in Node.js fairly
> > quickly if the info callback issue was solved openssl side. I'm even
> > happy to help work on it if that's an issue, it would be more
> > productive than what I've been trying to do in Node.js.
> 
> In case anyone missed it I opened a PR for this over the weekend:
> 
> https://github.com/openssl/openssl/pull/8096
> 
> I'm leaving it there for a day or two for people to comment. Assuming no major
> issues are identified I'll will raise an OMC vote for it.

Can I suggest you just describe what the patch does, and call a
vote on that?


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

2019-01-30 Thread Kurt Roeckx
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


Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
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



Re: VOTE Apply PR#9084 reverting DEVRANDOM_WAIT

2019-06-07 Thread Kurt Roeckx
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

2019-06-07 Thread Kurt Roeckx
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

2019-06-07 Thread Kurt Roeckx
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

2019-06-07 Thread Kurt Roeckx
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

2019-06-07 Thread Kurt Roeckx
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

2019-06-07 Thread Kurt Roeckx
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: Start up entropy gathering

2019-06-13 Thread Kurt Roeckx
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



Vote proposal: votes should get discussed first

2019-05-12 Thread Kurt Roeckx
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: Do we really want to have the legacy provider as opt-in only?

2019-07-16 Thread Kurt Roeckx
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: Thread sanitiser problems

2019-07-30 Thread Kurt Roeckx
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: Thread sanitiser problems

2019-07-30 Thread Kurt Roeckx
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: Do we really want to have the legacy provider as opt-in only?

2019-07-16 Thread Kurt Roeckx
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: Two Travis Jobs are failing on master

2019-07-23 Thread Kurt Roeckx
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



New audit before 3.0 release

2019-11-10 Thread Kurt Roeckx
Should we let someone do a new audit before the 3.0 release?


Kurt



Re: Build failures on master?!

2019-11-18 Thread Kurt Roeckx
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



Re: Deprecations

2020-03-04 Thread Kurt Roeckx
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)

2020-02-28 Thread Kurt Roeckx
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



Deprecations

2020-02-21 Thread Kurt Roeckx
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: Deprecations

2020-02-21 Thread Kurt Roeckx
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



Re: Deprecations

2020-02-21 Thread Kurt Roeckx
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

2020-02-21 Thread Kurt Roeckx
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: Should the return result of CRYPTO_UP_REF() / CRYPTO_DOWN_REF() be checked?

2020-02-10 Thread Kurt Roeckx
On Mon, Feb 10, 2020 at 04:19:20PM +, Matt Caswell wrote:
> 
> 
> On 10/02/2020 00:15, SHANE LONTIS wrote:
> > With the new architecture changes there are quite a few new calls to
> > 
> > CRYPTO_UP_REF()
> > CRYPTO_DOWN_REF()
> > 
> > These methods return an int that is not being checked in lots of places.
> > 
> > This return value only seems to affect fallback code that calls 
> > CRYPTO_atomic_add (which can return 0 on lock or unlock failure)
> > 
> > SO the question is should we be checking this return value?
> 
> Yes, I think we should be.

I think that as long as we have that fallback code, that it should
be checked.


Kurt



Re: Github PR label automation

2020-02-11 Thread Kurt Roeckx
On Sat, Feb 08, 2020 at 03:56:19PM +, Mark J Cox wrote:
> So right now here's what it does:
> 
> Every hour it looks at open PRs that are labelled "approval: done".
> If 24 hours has elapsed since that label was assigned and if there
> have been no comments made to the PR since the label was assigned then
> it is automatically moved to "approval: ready to merge" with a comment
> added to trigger notifications.  So if you want to stop something
> going to "ready to merge" just add any comment to the PR.

Does it also check that the CI says that everything is OK?


Re: crypt(3)

2020-01-17 Thread Kurt Roeckx
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: crypt(3)

2020-01-19 Thread Kurt Roeckx
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)

2020-01-18 Thread Kurt Roeckx
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: Legacy Provider

2020-01-08 Thread Kurt Roeckx
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



  1   2   >