Re: [openssl-project] Beta release on Tuesday

2018-04-27 Thread Salz, Rich
>As normal we are planning a new beta release on Tuesday. This means that >we will be freezing the repo from Monday afternoon (UTC). I'm in US but available if nobody "closer" can do it. ___ openssl-project mailing list

[openssl-project] FW: [TLS] WGLC for draft-ietf-tls-tls13-vectors

2018-05-08 Thread Salz, Rich
Anyone want to take a look at wedging this into our test suite? On 5/8/18, 12:31 PM, "Sean Turner" wrote: All, This is the working group last call for the "Example Handshake Traces for TLS 1.3" draft available at

Re: [openssl-project] Current votes FYI

2018-05-23 Thread Salz, Rich
ote simply did not pass. Tim. On Thu, 24 May 2018, 12:59 am Salz, Rich, <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: Another update VOTE: Remove the second paragraph ("Binary compatibility...improve security") from the relea

Re: [openssl-project] build/test before merging

2018-05-23 Thread Salz, Rich
>Unfortunately, I didn't have time to follow my vision yet. Also, it would > have been easier for me to do it in Python than in Perl. +1 for python! :) ___ openssl-project mailing list openssl-project@openssl.org

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

2018-06-07 Thread Salz, Rich
I see you already started the votes. No time for discussion? I think OpenSSL should be a "fundamental" system library. Perhaps the apps are different, but it should not require new libraries but could use them if available -- either at run-time or via config/build. I think iconv in

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

2018-06-07 Thread Salz, Rich
>Taking off on a bit of a tangent, how much justification did we go through when adding pthreads as a dependency. It's an optional, but enabled by default, dependency which is different. We had a lot of discussion within what was then openssl-team.

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

2018-06-07 Thread Salz, Rich
>We don't have to answer the question "how high" now. I'm fully prepared to have the use of iconv limited to platforms where we know it's available That then means that the pkcs12 program is not compatible in behavior across platforms. This would be a first, for us.

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

2018-06-07 Thread Salz, Rich
>My main concern is that currently, openssl pkcs12 may create broken pkcs12 > files (because it misinterprets the pass phrase when constructing a > BMPString), and doesn't notify the user at all (doesn't even check). For those who haven't reada the PR and all its comments, I propose that

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

2018-06-07 Thread Salz, Rich
>So even rejecting correctly encoded utf-8? I think you forgot that this is not what I suggested. One flag indicates it's utf-8 encoded, don't touch it. The other flag indicates it might have high-bit chars, don't touch it. ___

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

2018-06-07 Thread Salz, Rich
password to valid UTF-8 encoding if this flag is given. On 6/7/18, 3:42 PM, "Salz, Rich" wrote: >So even rejecting correctly encoded utf-8? I think you forgot that this is not what I suggested. One flag indicates it's utf-8 encoded, don't touch it. The other f

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

2018-06-11 Thread Salz, Rich
>Except that, because of the way PKCS12_gen_mac() works, this isn't true. If the input pass phrase looks like a UTF-8 encoded string (because there are valid characters in other encodings that will like like UTF-8 byte sequences), it will be used as if -passutf8 was given

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

2018-06-11 Thread Salz, Rich
> If B<-pass8bit> is given, the password is taken to be encoded in the current > locale, but is still used directly. > A future release might automatically convert the password to valid UTF-8 > encoding if this flag is given. I would propose that "-pass8bit" means that

Re: [openssl-project] [openssl-omc] stepping down from OMC

2018-06-11 Thread Salz, Rich
* I'm leaving the project. https://www.youtube.com/watch?v=YtsZoIe3Czk You have a great deal to be proud of, and OpenSSL is much better for the time you spent here. We will miss you. I will miss you. ___ openssl-project mailing list

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

2018-06-11 Thread Salz, Rich
>However, what's going to happen is that PKCS12_gen_mac() will generate this for a BMPString: Which is what we do now, right? And the docs for this *new flag* explain that the behavior could change in the future. To be "pass8bit" means "pass 8bit bytes through to lower layer" But if

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

2018-06-11 Thread Salz, Rich
>I have zero idea what the doc says, because I haven't seen the docs yet. Did I miss the PR? No. It's posted here on the mailing list for discussion and reposted here: +=item B<-passutf8>, B<-pass8bit> + +These flags indicate the character set encoding on the password value. +By

Re: [openssl-project] Beta release today

2018-06-19 Thread Salz, Rich
>It would still be good if someone can freeze the repo though please: ssh openssl-...@git.openssl.org freeze openssl matt I will do this tonight, eastern time. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] Is Mac a supported platform?

2018-06-01 Thread Salz, Rich
>Regarding the original question, it's "supported" insofar that we have osx among the Travis builds (at least usually... there have been times when the osx backlog has been so great that we've temporarly disabled it). So maybe I should just create a PR to update INSTALL with

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

2018-06-01 Thread Salz, Rich
>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. ___

Re: [openssl-project] Is Mac a supported platform?

2018-06-02 Thread Salz, Rich
https://github.com/openssl/openssl/pull/6404 On 6/1/18, 5:33 PM, "Richard Levitte" wrote: In message <1bd96940-3b3b-4758-938a-01e576306...@akamai.com> on Fri, 1 Jun 2018 21:26:12 +0000, "Salz, Rich" said: rsalz> >Regarding the original qu

[openssl-project] FW: [openssl-commits] Build failed in Jenkins: master_noec #574

2018-06-26 Thread Salz, Rich
FYI On 6/26/18, 2:45 PM, "Barry Fussell (bfussell)" wrote: The evp_test is failing intermittently because there is an attempt to malloc zero bytes when running the new test that came in with this commit.

[openssl-project] GitHub labels

2018-06-20 Thread Salz, Rich
I think it’s a good idea that we periodically review the labels we’re using. Please look at https://github.com/openssl/openssl/labels and maybe suggest changes. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] Milestones and the 1.1.1 release

2018-07-02 Thread Salz, Rich
Thanks for finishing this off. https://github.com/openssl/openssl/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.1.1 Are 6512 and 6396 the same, and closed because we made things more secure? Is 6342 a python bug, they'll need to upgrade? Is 6228 a foolscap issue? I think we can close

Re: [openssl-project] Freezing the repo

2018-04-30 Thread Salz, Rich
Done. On 4/30/18, 3:02 PM, "Matt Caswell" wrote: Please could someone freeze the repo for me for tomorrow's release: $ ssh openssl-...@git.openssl.org freeze openssl matt Thanks Matt ___

Re: [openssl-project] Beta release on Tuesday

2018-04-30 Thread Salz, Rich
>Nobody else has stepped forward. Are you still available for this? Sure. >I would normally start around 12.00 UTC, but could push it a bit later if it works better for you. So that's 7am, it would be best to delay an hour. ___

[openssl-project] Draft Travel Reimbursement policy

2018-01-29 Thread Salz, Rich
At the London F2F I had the action item to draft a travel reimbursement policy. Here’s a starting point. After discussion dies down I’ll post it to the bureau and vote. The OpenSSL project may pay travel expenses for OMC members when pre-approved by the OMC or when it is an official OMC

[openssl-project] FW: [Dcrup] WGLC final issues draft-ietf-dcrup-dkim-crypto

2018-02-01 Thread Salz, Rich
Can anyone lend John a hand with ed25519 signatures via command-line? This is important for the next version of domain-key email signing (spam avoidance) On 2/1/18, 2:14 PM, "John Levine" wrote: In article <3569aeba-5089-4827-8c18-ec13246bc...@akamai.com> you write:

Re: [openssl-project] chatty make output

2018-02-01 Thread Salz, Rich
it used to do. Also, the message is geared to disappear with 1.1.1a or above. Cheers Richard "Salz, Rich" <rs...@akamai.com> skrev: (1 februari 2018 18:00:57 CET) I think this belongs in CHANGES or NEWS, not with every single reconfigure build Creating Makefile NOTE:

[openssl-project] chatty make output

2018-02-01 Thread Salz, Rich
I think this belongs in CHANGES or NEWS, not with every single reconfigure build Creating Makefile NOTE: Starting with OpenSSL 1.1.1, 'Configure' doesn't display all the disabled options or the "make variables" with their values. Instead, you must use 'configdata.pm' as a script to get a

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

2018-02-05 Thread Salz, Rich
➢ In general we should prefer ossl_assert over assert. Never use OPENSSL_assert() in libcrypto or libssl. Maybe that’s all to put into the guide, then. ___ openssl-project mailing list openssl-project@openssl.org

[openssl-project] FW: CT Order Confirmation - OPENSSL SOFTWARE SERVICES INC.

2018-02-05 Thread Salz, Rich
I filed the annual registration for OpenSSL Software Services and paid with the OpenSSL credit card. From: CT Corporation Reply-To: "[DO NOT REPLY] CT Corporation" Date: Monday, February 5, 2018 at 1:32 PM To: "rs...@openssl.org"

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

2018-02-05 Thread Salz, Rich
A summary of the discussion thread so far. Not surprisingly, it’s all about the whitespace. :) The descriptions here were written to be understandable stand-alone. Once we come to a conclusion, we’ll wordsmith them into the coding style. Do not put a size after sizeof; do use parens. When

[openssl-project] FW: [vendor-meetings] Invitation to the 2018 CERT Vendor Meeting [INFO#384036]

2018-02-08 Thread Salz, Rich
IN case anyone is going to be in the area. On 2/8/18, 2:26 PM, "Art Manion" wrote: The CERT Coordination Center invites you to attend the 2018 CERT Vendor Meeting. The meeting will be held on Monday April 16, 2018, at the Westin St. Francis in San Francisco,

Re: [openssl-project] Code freeze later today

2018-02-12 Thread Salz, Rich
Please try to walk through and use the release instructions in the tool repo and fix any errors. On 2/12/18, 6:24 AM, "Matt Caswell" wrote: Tomorrow we are doing our first alpha release. Therefore I plan to call a code freeze from later today until after the release

Re: [openssl-project] Style question

2018-02-12 Thread Salz, Rich
The error return is not documented. We are definitely moving to a "don't check params for NULL". I would like to see this changed to be the obvious one-liner. Tim will disagree, but he's on the wrong side of history :) ___ openssl-project mailing

Re: [openssl-project] Removing assembler for outdated algorithms

2018-02-10 Thread Salz, Rich
mbler for outdated algorithms Before we look at removing things like this, I think we should look at whether or not they actually have a significant maintenance cost. Tim. On 11 Feb. 2018 7:08 am, "Salz, Rich" <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: This is

Re: [openssl-project] Removing assembler for outdated algorithms

2018-02-10 Thread Salz, Rich
I am not suggesting we remove blowfish or any of those algorithms. I am suggesting we remove the assembler versions of them. On 2/10/18, 5:33 PM, "Viktor Dukhovni" <vik...@dukhovni.org> wrote: On Sat, Feb 10, 2018 at 10:19:20PM +, Salz, Rich wrote: >

[openssl-project] Removing assembler for outdated algorithms

2018-02-10 Thread Salz, Rich
This is derived from bureau/libcrypto-proposal that Emilila made in November 2015. We should remove the assembler versions of the following Blowfish, cast, des, rc4, rc5, ripemd, whirlpool, md5 The reason is that they are outdated, not in use very much, and optimization is not

Re: [openssl-project] Removing assembler for outdated algorithms

2018-02-10 Thread Salz, Rich
significant maintenance cost. Tim. On 11 Feb. 2018 7:08 am, "Salz, Rich" <rs...@akamai.com<mailto:rs...@akamai.com>> wrote: This is derived from bureau/libcrypto-proposal that Emilila made in November 2015. We should remove the assembler versions of the following

Re: [openssl-project] Removing assembler for outdated algorithms

2018-02-11 Thread Salz, Rich
> Those same systems will probably not have the newest OpenSSL either, and OpenSSH on those machines will certainly not be linked with a newer OpenSSL... I apologize for not being clear enough. I do not want to remove any of those algorithms. I just want to remove 10,000 lines

Re: [openssl-project] Removing assembler for outdated algorithms

2018-02-11 Thread Salz, Rich
> So we should tread with some care. Perhaps the software-only Blowfish is fast enough, but my point is that Blowfish is much less of an obvious outdated cipher than the others... That's a different point. I still don't agree. The difference between hand-tuned assembler and C

Re: [openssl-project] Removing assembler for outdated algorithms

2018-02-11 Thread Salz, Rich
>I'm worried that the number could go down to zero some day. I do see the > benefits with the assembly code and personally find then justifiable enough > to try and learn. I am not at all worried about that. The best current algorithms will always benefit from assembler. It's just

Re: [openssl-project] Removing assembler for outdated algorithms

2018-02-10 Thread Salz, Rich
> Is blowfish actually outdated? I thought it had some significant use, > and don't recall any major weakness... In particular, IIRC OpenSSH uses blowfish, and links to OpenSSL for the underlying cipher... PGP use to be a heavy user, but now it only decrypts or does

Re: [openssl-project] Draft Travel Reimbursement policy

2018-02-09 Thread Salz, Rich
Any commentary on this? Otherwise I’ll do a (two-week) vote next week. From: Rich Salz Reply-To: "openssl-project@openssl.org" Date: Monday, January 29, 2018 at 11:18 AM To: "openssl-project@openssl.org" Subject:

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

2018-02-05 Thread Salz, Rich
* nit: Do not put a space after sizeof. fixed. * 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? It already says that. ___ openssl-project mailing

[openssl-project] Coding style updates

2018-02-16 Thread Salz, Rich
I’ve written up everything that seemed to have agreement, and kept the couple of items where it was less clear. Please comment here: https://github.com/openssl/web/pull/43 I want to do a vote by the end of the month. ___ openssl-project mailing list

Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Salz, Rich
>it's NULL. Now imagine that this stack was some kind of deny list. If >entry producer didn't pay attention to error when creating stack and >putting things into it, consumer would be led to belief that there is >nothing to deny and let through the requests that are supposed to be

Re: [openssl-project] Removal of NULL checks

2018-08-09 Thread Salz, Rich
>Whether one's for them, or against them, removing a check from a function that would formerly return an error and making it crash is a substantial API change. I don't disagree. ___ openssl-project mailing list

Re: [openssl-project] Reuse of PSKs between TLSv1.2 and TLSv1.3

2018-08-09 Thread Salz, Rich
>"We should remove the TLSv1.2 to TLSv1.3 PSK compatibility mechanism as discussed in issue 6490. If TLSv1.2 PSKs are configured (and not TLSv1.3 PSKs) then we should disable TLSv1.3." This seems reasonable to me, albeit a bit wordy since you could delete the first sentence. :)

[openssl-project] TLS 1.3 and the release

2018-08-11 Thread Salz, Rich
You probably know by now that TLS 1.3 was just released as RFC 8446;

[openssl-project] FW: Certificate fractional time processing in upcoming openssl releases

2018-08-11 Thread Salz, Rich
So it seems counter to the spirit of the RFC to prevent openSSL from being able to interoperate with certs issued by IAIK or whatever noncompliant systems. Thanks, David From: "Salz, Rich" mailto:rs...@akamai.com>> Date: Friday, August 10, 2018 at 12:24 PM To: "Barry Fus

Re: [openssl-project] Releases tomorrow

2018-08-13 Thread Salz, Rich
>- "Updates for RFC8446 (the final TLSv1.3 version)" (PR 6741) needs to be merged. I have the required approval, just giving Rich some time to see if he has any further comments. Thanks, I'm good. >- If we're going to make any changes for issue 6904 (broken pipe for clients

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

2018-08-14 Thread Salz, Rich
I mean keep the *previous* behavior. On 8/14/18, 9:25 AM, "Salz, Rich" wrote: >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?

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

2018-08-14 Thread Salz, Rich
>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? Keep the existing behavior for 1.0.2, 1.1.0 and 1.1.1. Sadly. And fix in a future release (I would re-open the

[openssl-project] Fractional seconds, etc.

2018-08-14 Thread Salz, Rich
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

[openssl-project] Taking a break

2018-07-20 Thread Salz, Rich
I am going to take a break from most of OpenSSL governance for the rest of the month. As I have been mostly the person handling all those other things, and as I am usually very very quick with email, I thought the project should know. I’m not going anywhere, it’s really just like the first

Re: [openssl-project] master is broken?

2018-07-24 Thread Salz, Rich
On 7/24/18, 1:42 PM, "Richard Levitte" wrote: Would you mind installing it? The package is called libcarp-always-perl on Debian and derivates, and if my RPM search fu isn't entirely off, the corresponding RPM package is perl-Carp-Always Or install with cpan... Okay.

Re: [openssl-project] master is broken?

2018-07-24 Thread Salz, Rich
sudo cpan Carp::Always I did this. Same results for config and the PERLOPT setting. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] master is broken?

2018-07-24 Thread Salz, Rich
; env | grep PERL ; PERL5OPT=-MCarp::Always ./config Operating system: x86_64-whatever-linux2 Can't locate Carp/Always.pm in @INC (you may need to install the Carp::Always module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5

[openssl-project] master is broken?

2018-07-24 Thread Salz, Rich
; g status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean ; g pull Current branch master is up to date. ; ; ./config Operating system: x86_64-whatever-linux2 Configuring OpenSSL version 1.1.1-pre9-dev (0x10101009L) for linux-x86_64

[openssl-project] Finishing up this release

2018-07-12 Thread Salz, Rich
We’re close to finishing the 1.1.1 release. As we’ve said before, this is our next LTS release which means it will be supported for five years. There are a few things we still need to do and we’re encouraging the community to help. These include: Address all the “1.1.1” open issues, found at

[openssl-project] External contributors and the next release

2018-03-06 Thread Salz, Rich
I think we should make sure to set aside time to review as many of the non-project pull requests as possible. I think it is important to show a commitment to the larger community. One way to do this is to say that we will extend the BETA date by a week, and in that week no new code from the

[openssl-project] Copyrights, AUTHORS file, etc.

2018-03-12 Thread Salz, Rich
For some background you can take a look at https://github.com/openssl/openssl/pull/5499 and the blog posts here: https://www.openssl.org/blog/blog/categories/license/ The OMC voted in 2014 to work to an eventual change of license to Apache 2. That led to the CLA’s. We had calls with various

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

2018-03-10 Thread Salz, Rich
>Well, the condition for this vote is a bit extraordinary as well. I couldn't in good conscience propose a week long vote, because that potentially would have the effect to push the release a week anyway, because the release would have to wait for the result of the vote. We

Re: [openssl-project] OID policy

2018-03-14 Thread Salz, Rich
No there is no policy. We should have OID's for the things we implement ( On 3/14/18, 6:28 PM, "Paul Dale" wrote: Is there a policy about filling in missing OIDs in objects.txt? I noticed that AES-128-XTS is in objects.txt but doesn't include an OID even

[openssl-project] Applying system defaults to TLS config

2018-03-15 Thread Salz, Rich
https://github.com/openssl/openssl/pull/4848 The crux of the issue is that this would change SSL_CTX to apply system defaults when the object is created. In conjunction with the system config file include stuff, this makes it easy to change the behavior of all applications running on a system.

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

2018-03-14 Thread Salz, Rich
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. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] OpenSSL FIPS Wiki Update

2018-03-14 Thread Salz, Rich
No mention of whether or not this will apply to EVERYTHING in a program, or will it be left to administrative guidance. Your thoughts, for example, on a “FIPS mode” flag for SSL or SSL_CTX? At a minimum, that needs to be listed as a stakeholder requirement (from Akamai). From:

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

2018-03-13 Thread Salz, Rich
So a major reason, as you explained, for having per-thread DRBG's is to reduce contention. When threadA creates an SSL object, the parent DRBG will be the threadA one. Therefore you have to introducing locking, since threadA might create two SSL objects and they could end up being used in

[openssl-project] Entropy seeding the DRBG

2018-04-03 Thread Salz, Rich
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

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

2018-04-07 Thread Salz, Rich
I would like to see this put on hold until we fix the ‘now requires 50% more random seeding’ issue. What should I do to force that issue? From: Richard Levitte Reply-To: openssl/openssl

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

2018-04-08 Thread Salz, Rich
>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. My expectation was that the *maximum* would also be 128

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

2018-04-08 Thread Salz, Rich
rsalz> My expectation was that the *maximum* would also be 128 bits. >Not sure what you're saying there. If the entropy acquisition routines is over enthusiastic and delivers 277 bits of entropy, are you saying it shouldn't be allowed to? I meant to say that the

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

2018-04-08 Thread Salz, Rich
kurt> So then I suggest we support the syscalls on all platforms that kurt> provide it. Who takes responsibility for fixing this? ___ openssl-project mailing list openssl-project@openssl.org

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

2018-04-08 Thread Salz, Rich
>The 384 comes straight out of SP800-90A, see the table 10.2.1. I think we're getting close to needing a team vote on whether or not we want to follow SP800-90A for this release. ___ openssl-project mailing list openssl-project@openssl.org

Re: [openssl-project] Entropy seeding the DRBG

2018-04-04 Thread Salz, Rich
>Note that with a nonce, that'll be 192 bits, unless I'm thinking wrong... But I agree with you, at least from a very practical point of view. I think using a nonce is needless. Use a personalization string (I used the address of the new DRBG).

Re: [openssl-project] Entropy seeding the DRBG

2018-04-04 Thread Salz, Rich
Is it expected that the number of bits of seed must equal the number of bits in the key strength? But at any rate, raising the seed size to 256 seems mildly tolerable, although I would prefer to keep it at 128. Raising it to 384 is wrong. ___

[openssl-project] Vote results

2018-04-05 Thread Salz, Rich
results: 7 yes, 1 no-vote topic: Feature changes in 1.1.1 directly related to TLSv1.3 will be allowed during the beta as long as at least 3 OMC members approve the change Proposed by Matt Caswell Public: yes opened: 2018-03-29 closed: 2018-04-05 ONE WEEK VOTE

[openssl-project] build broken?

2018-04-05 Thread Salz, Rich
Making update CONF function code 122 collision at CONF_F_SSL_MODULE_INIT diff --git a/crypto/err/openssl.txt b/crypto/err/openssl.txt index d1cc039..de3dacc 100644 --- a/crypto/err/openssl.txt +++ b/crypto/err/openssl.txt @@ -335,7 +335,7 @@ CONF_F_NCONF_LOAD_BIO:110:NCONF_load_bio

Re: [openssl-project] Some TLS 1.3 drafts don't have branches

2018-04-12 Thread Salz, Rich
+1 On 4/12/18, 5:51 AM, "Matt Caswell" <m...@openssl.org> wrote: On 12/04/18 02:42, Salz, Rich wrote: > ; g branch -r -v -a | grep -i draft > > remotes/origin/tls1.3-draft-18 669c623 Update PR#3925 > >

Re: [openssl-project] FIPS support and sponsorship

2018-04-11 Thread Salz, Rich
Hi there. I’m happy to talk and can explain things based on our public statements and policies so far. I’m based in Boston. (We’ll invite anyone else from the team in case they want to attend as well.) From: Phillip Moore Reply-To: "openssl-project@openssl.org"

Re: [openssl-project] FIPS support and sponsorship

2018-04-11 Thread Salz, Rich
Hi there. I’m happy to talk and can explain things based on our public statements and policies so far. I’m based in Boston. (We’ll invite anyone else from the team in case they want to attend as well.) From: Phillip Moore Reply-To: "openssl-project@openssl.org"

[openssl-project] VOTE on coding style changes

2018-04-09 Thread Salz, Rich
This email starts a vote. Two notes: The contents of the PR are also attached. I have BCC’d openssl-project, for public notification about the vote. I’m not sure if this is the best way to do things, but it’s worth a shot. Incorporate the text topic: Incorporate

Re: [openssl-project] VOTE on coding style changes

2018-04-09 Thread Salz, Rich
This is an old message that had been held up in the moderator queue. Ignore it. From: Rich Salz Reply-To: "openssl-project@openssl.org" Date: Monday, April 9, 2018 at 10:02 PM To: "openssl-...@openssl.org" Subject:

[openssl-project] Vote results -- coding style

2018-04-09 Thread Salz, Rich
This vote failed. It was two in favor, two opposed, three no-care, and one not voting. I hope someone else will pick this up and run with it. I am closing the PR. topic: Incorporate the text of https://github.com/openssl/web/pull/43 into the coding style policy.

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

2018-04-07 Thread Salz, Rich
>NIST SP800-90A rev1 section 8.6.7 has: Compliance with this was never a stated goal of this release. So not relevant. ___ 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 Salz, Rich
>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

Re: [openssl-project] build broken?

2018-04-05 Thread Salz, Rich
u make a PR from this? In message <f3e1c9d0-51f2-4dea-84a6-545d1df01...@akamai.com> on Thu, 5 Apr 2018 17:18:13 +, "Salz, Rich" <rs...@akamai.com> said: rsalz> Making update rsalz> CONF function code 122 collision at CONF_F_SSL_MODULE_INIT rsalz> rsal

[openssl-project] Some TLS 1.3 drafts don't have branches

2018-04-11 Thread Salz, Rich
; g branch -r -v -a | grep -i draft remotes/origin/tls1.3-draft-18 669c623 Update PR#3925 remotes/origin/tls1.3-draft-19 d4d9864 Update PR#3925 ; I recently had someone need draft-21 and they did git checkout 515982154031b679f58d5e2cbd7752294779221e Can we create

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

2018-04-14 Thread Salz, Rich
I have not heard that any application program -- NOT COUNTING OUR TESTS -- that break. The one counterpoint we have is that s_client/s_server work. ___ openssl-project mailing list openssl-project@openssl.org

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

2018-04-14 Thread Salz, Rich
We have *no* data points, except our tests, that anything fails to work. In fact, we are increasingly collecting data that shows everything is just fine. I believe we were led into the current situation, because our tests don't completely work *going backwards.* Do the 1.1.0 tests basically

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

2018-04-18 Thread Salz, Rich
>Would still like to know what's motivating Google's insistence on SNI... The TLS WG is probably the place to ask this. ___ 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-16 Thread Salz, Rich
I think this is a great idea, but that it is way too late for this release. We really should be concentrating on testing and fixes, and open PR's and other release criteria. Ideally the release goes out in a month (IETF RFC editor willing) ___

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

2018-04-15 Thread Salz, Rich
> I believe we were led into the current situation, because our tests don't completely work *going backwards.* Do the 1.1.0 tests basically work *going forwards* ? >It is unclear what you mean by forwards and backwards, but some 1.1.0 tests failed when using a 1.1.1 library.

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

2018-04-15 Thread Salz, Rich
Tim and Viktor have convinced me that “it’s not worth it” is wrong. Thanks, Richard, for testing 1.1.0 tests with 1.1.1 library. We do need to analyze the results and not say any failure means something 1.1.1 has to fix – it could be failing because of an assumption in the 1.1.0 tests. Am I

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

2018-04-19 Thread Salz, Rich
>Self assigning is a good habit... unless you have my tendencies, to *ahem* forget that you've self assigned something. There's a built-in filter that says "find my PR's" It's just on the left side of the search box. ___ openssl-project

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

2018-04-19 Thread Salz, Rich
I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or something like that. David has pointed out valid use-cases. I think most use-cases will "just work." We should document the known sharp edges. ___ openssl-project

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

2018-04-17 Thread Salz, Rich
So far, if there's no SNI then we shouldn't do TLS 1.3 (as a client). That seems easy to code. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project

[openssl-project] About PR 5702, etc.

2018-03-27 Thread Salz, Rich
Discussion seems to have stalled out on this. Please review https://github.com/openssl/openssl/pull/5702 if necessary. Do folks want a general “TLS 1.3 is okay post-freeze” policy? I don’t know, but I think it will take too long to get to a decision. Is anyone (on the OMC) going to take that

Re: [openssl-project] Speeding up the fuzz test...

2018-03-27 Thread Salz, Rich
Neat. What does CPIO have over TAR? Is it better enough that it is a compelling reason to introduce yet another file format? ___ 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 Salz, Rich
>Please note that that 50% extra is only used for instantiating the DRBG. On reseed we it only uses 256 bits. True. And now we're finding that VMS won't work. And I bet there are other systems that will also find this amount excessive. >There is an alternative to that 50%

  1   2   >