From levitte at openssl.org  Mon Apr  2 08:13:53 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 02 Apr 2018 10:13:53 +0200 (CEST)
Subject: [openssl-project]  Code freeze later today
Message-ID: <20180402.101353.1049094474945587407.levitte@openssl.org>

Hi,

A reminder, we're releasing beta 2 tomorrow.  In preparation, we will
do as usual, freeze the repo, which will happen some time this evening
(Swedish time).

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kurt at roeckx.be  Mon Apr  2 21:39:36 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 2 Apr 2018 23:39:36 +0200
Subject: [openssl-project] Code freeze later today
In-Reply-To: <20180402.101353.1049094474945587407.levitte@openssl.org>
References: <20180402.101353.1049094474945587407.levitte@openssl.org>
Message-ID: <20180402213936.GA29107@roeckx.be>

On Mon, Apr 02, 2018 at 10:13:53AM +0200, Richard Levitte wrote:
> Hi,
> 
> A reminder, we're releasing beta 2 tomorrow.  In preparation, we will
> do as usual, freeze the repo, which will happen some time this evening
> (Swedish time).

So when will that be?


Kurt


From levitte at openssl.org  Mon Apr  2 23:19:25 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 03 Apr 2018 01:19:25 +0200 (CEST)
Subject: [openssl-project] Code freeze later today
In-Reply-To: <20180402213936.GA29107@roeckx.be>
References: <20180402.101353.1049094474945587407.levitte@openssl.org>
 <20180402213936.GA29107@roeckx.be>
Message-ID: <20180403.011925.516444712877874805.levitte@openssl.org>

In message <20180402213936.GA29107 at roeckx.be> on Mon, 2 Apr 2018 23:39:36 +0200, Kurt Roeckx <kurt at roeckx.be> said:

kurt> On Mon, Apr 02, 2018 at 10:13:53AM +0200, Richard Levitte wrote:
kurt> > Hi,
kurt> > 
kurt> > A reminder, we're releasing beta 2 tomorrow.  In preparation, we will
kurt> > do as usual, freeze the repo, which will happen some time this evening
kurt> > (Swedish time).
kurt> 
kurt> So when will that be?

Now.

I'm sorry, I fell asleep very early yesterday, only to wake up just
after midnight.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Tue Apr  3 12:52:50 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 3 Apr 2018 12:52:50 +0000
Subject: [openssl-project] Entropy seeding the DRBG
Message-ID: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>

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.

Thoughts?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180403/dcc11c5f/attachment.html>

From levitte at openssl.org  Tue Apr  3 13:28:38 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 03 Apr 2018 15:28:38 +0200 (CEST)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
Message-ID: <20180403.152838.1105373056478347916.levitte@openssl.org>

In message <DA29A952-D1E7-44ED-8BE9-115E073A517B at akamai.com> on Tue, 3 Apr 2018 12:52:50 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> I had not realized that we just increased the ?entropy?
rsalz> requirements by 50%, from 256 to 384. The original DRBG
rsalz> submission that I did only required 128 bits.  I think that is
rsalz> wrong, and I think the PR that did it (#5503) should be
rsalz> reverted.
rsalz> 
rsalz> I am concerned that we are trying to meet requirements that we
rsalz> really don?t have.  The original code was a huge improvement.
rsalz> 
rsalz> Requiring 384 bits of random seed is silly.  I think it is
rsalz> ridiculous.  One way or another we HAVE to fix that before the
rsalz> release.
rsalz> 
rsalz> Thoughts?

FYI, here's the magic number that lies behind this:

    : ; git grep RAND_DRBG_STRENGTH
    ...
    include/openssl/rand_drbg.h:# define RAND_DRBG_STRENGTH             256

The requirement change from 128 to 256 happened with this commit:

    commit 32bda2b2e4900308cb025020d8c8692e1d3c2ba9
    Author: Kurt Roeckx <kurt at roeckx.be>
    Date:   Sun Feb 18 19:16:13 2018 +0100
    
        Switch the DRBGs from AES-128-CTR to AES-256-CTR
        
        Reviewed-by: Dr. Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com>
        GH: #5401

And then there's this one, which did the added 50%:

    commit 2a70d65b99e1f2376be705d18bca88703b7e774a
    Author:     Kurt Roeckx <kurt at roeckx.be>
    AuthorDate: Sat Mar 3 23:19:03 2018 +0100
    Commit:     Kurt Roeckx <kurt at roeckx.be>
    CommitDate: Sun Apr 1 21:11:26 2018 +0200
    
        Make sure we use a nonce when a nonce is required
        
        If a nonce is required and the get_nonce callback is NULL, request 50%
        more entropy following NIST SP800-90Ar1 section 9.1.
        
        Reviewed-by: Dr. Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com>
        GH: #5503
    
Each of them seen by itself make sense.  The combined result, though,
leaves me wondering...

(I'm tempted to try this with /dev/random only on Unix...  do I
remember it right, that it blocks for a while after every 8 byte chunk
on some Unixen?)

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From openssl at openssl.org  Tue Apr  3 13:46:24 2018
From: openssl at openssl.org (OpenSSL)
Date: Tue, 3 Apr 2018 13:46:24 +0000
Subject: [openssl-project] OpenSSL version 1.1.1 pre release 4 published
Message-ID: <20180403134624.GA18668@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.1.1 pre release 4 (beta)
   ===========================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 4 has now
   been made available. For details of changes and known issues see the
   release notes at:

        https://www.openssl.org/news/openssl-1.1.1-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The beta release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.1-pre4.tar.gz
      Size: 8259067
      SHA1 checksum: 28d83c6441d269660ca1571331bb830867b082d4
      SHA256 checksum: df2d5fcc2a878525611c75b9e9116fbcfbce8d9b96419a16eda5fb11ecc428f6

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.1-pre4.tar.gz
    openssl sha256 openssl-1.1.1-pre4.tar.gz

   Please download and check this beta release as soon as possible.
   To report a bug, open an issue on GitHub:

    https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaw4CRAAoJENnE0m0OYESR8/gH+wRA1A8TQnwUr9/keW8SGZrg
wxhgEh3q04yYTL7yGYMWn53TDLJR1TJN3viEKtS9vZ7/EIfytb7Q/Sf+dlEpy3GP
Fe5QWQu76DakiF5HHKVoVmcNyObA1sdNzqagxz/XhYkhUdjToOlqDhT0lkPg42ps
lidX68jqvZx2DfE5yjsHp4HzHwLsXVPcOILarX0OOIeG7mVS1k9fIqnVFsajnOhR
KJxMoyJ59pos0hsjA6ZHcjMpcaeXFEUYCqpPQYP/EqQz5h5q456HRovempB+GRM8
yUWAPAgaqfTlOz5Jx5+1SxFbKqFc+/Rkx2M3zpa15SuJ6R7cHZiS/JLlBXF+LiQ=
=x0tg
-----END PGP SIGNATURE-----

From matt at openssl.org  Tue Apr  3 13:50:13 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 3 Apr 2018 14:50:13 +0100
Subject: [openssl-project] Repo
Message-ID: <6836a5f7-cd9e-f7b6-fc40-35d9e498b084@openssl.org>

The repo is unfrozen (thawed?).

The release is done. Thanks to Richard again for all his help.

Matt

From rsalz at akamai.com  Tue Apr  3 14:55:55 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 3 Apr 2018 14:55:55 +0000
Subject: [openssl-project] FW: April Crypto Bulletin from Cryptosense
In-Reply-To: <6123dc021d88a3dbe3c81eeba.4a7a7251ad.20180403132421.0620ecd98c.f54bee76@mail179.wdc02.mcdlv.net>
References: <6123dc021d88a3dbe3c81eeba.4a7a7251ad.20180403132421.0620ecd98c.f54bee76@mail179.wdc02.mcdlv.net>
Message-ID: <93B32B79-18B9-4B0E-8D63-6161AE28166F@akamai.com>

This is one reason why keeping around old assembly code can have a cost. :(

https://github.com/openssl/openssl/pull/5320

Andy and Tim:  Still waiting for your response to my question in that PR ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180403/b113198d/attachment-0001.html>
-------------- next part --------------
An embedded message was scrubbed...
From: =?utf-8?Q?Cryptosense?= <contact at cryptosense.com>
Subject: April Crypto Bulletin from Cryptosense
Date: Tue, 3 Apr 2018 13:24:34 +0000
Size: 78044
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180403/b113198d/attachment-0001.mht>

From matt at openssl.org  Tue Apr  3 15:00:01 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 3 Apr 2018 16:00:01 +0100
Subject: [openssl-project] FW: April Crypto Bulletin from Cryptosense
In-Reply-To: <93B32B79-18B9-4B0E-8D63-6161AE28166F@akamai.com>
References: <6123dc021d88a3dbe3c81eeba.4a7a7251ad.20180403132421.0620ecd98c.f54bee76@mail179.wdc02.mcdlv.net>
 <93B32B79-18B9-4B0E-8D63-6161AE28166F@akamai.com>
Message-ID: <4d850789-3e92-cb69-8060-ef23194006f1@openssl.org>



On 03/04/18 15:55, Salz, Rich wrote:
> This is one reason why keeping around old assembly code can have a cost. :(

Although in this case the code is <2 years old:

commit e33826f01bd78af76e0135c8dfab3387927a82bb
Author:     Andy Polyakov <appro at openssl.org>
AuthorDate: Sun May 15 17:01:15 2016 +0200
Commit:     Andy Polyakov <appro at openssl.org>
CommitDate: Thu May 19 22:33:00 2016 +0200

    Add assembly CRYPTO_memcmp.

    GH: #102

    Reviewed-by: Richard Levitte <levitte at openssl.org>


Matt

From rsalz at akamai.com  Tue Apr  3 15:29:14 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 3 Apr 2018 15:29:14 +0000
Subject: [openssl-project] FW: April Crypto Bulletin from Cryptosense
In-Reply-To: <4d850789-3e92-cb69-8060-ef23194006f1@openssl.org>
References: <6123dc021d88a3dbe3c81eeba.4a7a7251ad.20180403132421.0620ecd98c.f54bee76@mail179.wdc02.mcdlv.net>
 <93B32B79-18B9-4B0E-8D63-6161AE28166F@akamai.com>
 <4d850789-3e92-cb69-8060-ef23194006f1@openssl.org>
Message-ID: <E91B1845-13CA-47A8-9019-3589F799BFF6@akamai.com>

    
    On 03/04/18 15:55, Salz, Rich wrote:
    > This is one reason why keeping around old assembly code can have a cost. :(
    
    Although in this case the code is <2 years old:

So?  It's code that we do not test, and have not tested in years.  And guess what?  Critical CVE.


From tjh at cryptsoft.com  Tue Apr  3 15:36:15 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Tue, 03 Apr 2018 15:36:15 +0000
Subject: [openssl-project] FW: April Crypto Bulletin from Cryptosense
In-Reply-To: <E91B1845-13CA-47A8-9019-3589F799BFF6@akamai.com>
References: <6123dc021d88a3dbe3c81eeba.4a7a7251ad.20180403132421.0620ecd98c.f54bee76@mail179.wdc02.mcdlv.net>
 <93B32B79-18B9-4B0E-8D63-6161AE28166F@akamai.com>
 <4d850789-3e92-cb69-8060-ef23194006f1@openssl.org>
 <E91B1845-13CA-47A8-9019-3589F799BFF6@akamai.com>
Message-ID: <CAHEJ-S7o+ztC8gF3ZN_J7qoFPiCbxTOBYfrXr8AVK6s15Hd8Cw@mail.gmail.com>

And it should have a test - which has nothing to do with ASM and everything
to do with improving test coverage.

Bugs are bugs - and any form of meaningful test would have caught this.

For the majority of the ASM code - the algorithm implementations we have
tests that cover things in a decent manner.

Improving tests is the solution - not whacking ASM code. Tests will catch
issues across *all* implementations.

Tim.


On Tue, 3 Apr. 2018, 8:29 am Salz, Rich, <rsalz at akamai.com> wrote:

>
>     On 03/04/18 15:55, Salz, Rich wrote:
>     > This is one reason why keeping around old assembly code can have a
> cost. :(
>
>     Although in this case the code is <2 years old:
>
> So?  It's code that we do not test, and have not tested in years.  And
> guess what?  Critical CVE.
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180403/492eba1b/attachment.html>

From levitte at openssl.org  Tue Apr  3 15:39:15 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 03 Apr 2018 17:39:15 +0200 (CEST)
Subject: [openssl-project] FW: April Crypto Bulletin from Cryptosense
In-Reply-To: <CAHEJ-S7o+ztC8gF3ZN_J7qoFPiCbxTOBYfrXr8AVK6s15Hd8Cw@mail.gmail.com>
References: <4d850789-3e92-cb69-8060-ef23194006f1@openssl.org>
 <E91B1845-13CA-47A8-9019-3589F799BFF6@akamai.com>
 <CAHEJ-S7o+ztC8gF3ZN_J7qoFPiCbxTOBYfrXr8AVK6s15Hd8Cw@mail.gmail.com>
Message-ID: <20180403.173915.1419263848062397591.levitte@openssl.org>

While I totally agree with the direction Tim is taking on this, we
need to remember that there's another condition as well: access to the
platform in question, either directly by one of us, or through someone
in the community.  Otherwise, we can have as many tests as we want, it
still won't test *that* code (be it assembler or something else)

In message <CAHEJ-S7o+ztC8gF3ZN_J7qoFPiCbxTOBYfrXr8AVK6s15Hd8Cw at mail.gmail.com> on Tue, 03 Apr 2018 15:36:15 +0000, Tim Hudson <tjh at cryptsoft.com> said:

tjh> And it should have a test - which has nothing to do with ASM and everything to do with improving
tjh> test coverage.
tjh> 
tjh> Bugs are bugs - and any form of meaningful test would have caught this.
tjh> 
tjh> For the majority of the ASM code - the algorithm implementations we have tests that cover things
tjh> in a decent manner.
tjh> 
tjh> Improving tests is the solution - not whacking ASM code. Tests will catch issues across *all*
tjh> implementations.
tjh> 
tjh> Tim.
tjh> 
tjh> On Tue, 3 Apr. 2018, 8:29 am Salz, Rich, <rsalz at akamai.com> wrote:
tjh> 
tjh>  On 03/04/18 15:55, Salz, Rich wrote:
tjh>  > This is one reason why keeping around old assembly code can have a cost. :(
tjh> 
tjh>  Although in this case the code is <2 years old:
tjh> 
tjh>  So? It's code that we do not test, and have not tested in years. And guess what? Critical CVE.
tjh> 
tjh>  _______________________________________________
tjh>  openssl-project mailing list
tjh>  openssl-project at openssl.org
tjh>  https://mta.openssl.org/mailman/listinfo/openssl-project
tjh> 

From kurt at roeckx.be  Tue Apr  3 16:54:09 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 3 Apr 2018 18:54:09 +0200
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
Message-ID: <20180403165409.GA22094@roeckx.be>

On Tue, Apr 03, 2018 at 12:52:50PM +0000, 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


From rsalz at akamai.com  Tue Apr  3 16:58:17 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 3 Apr 2018 16:58:17 +0000
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180403165409.GA22094@roeckx.be>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403165409.GA22094@roeckx.be>
Message-ID: <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>

>    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% extra, but it's not making
    sense to me.
  
Shrug.
  
>    The 1.1.0 version also used 256 bit.
  
The 1.1.0 code was pre-DRBG and was a piece of crap.  Using AES/DRBG is stronger, better, and for the normal case 128 bits is enough.




From tjh at cryptsoft.com  Tue Apr  3 16:58:49 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Wed, 4 Apr 2018 02:58:49 +1000
Subject: [openssl-project] FW: April Crypto Bulletin from Cryptosense
In-Reply-To: <20180403.173915.1419263848062397591.levitte@openssl.org>
References: <4d850789-3e92-cb69-8060-ef23194006f1@openssl.org>
 <E91B1845-13CA-47A8-9019-3589F799BFF6@akamai.com>
 <CAHEJ-S7o+ztC8gF3ZN_J7qoFPiCbxTOBYfrXr8AVK6s15Hd8Cw@mail.gmail.com>
 <20180403.173915.1419263848062397591.levitte@openssl.org>
Message-ID: <CAHEJ-S60qe9dmdL97+y+gQ8eqHd7VGgWXtVGwu10yPmjtrk1rA@mail.gmail.com>

I'm less concerned about that access in this specific instance - as if we
had a test in place for that function then make test on the platform would
have picked up the issue trivially.
I don't know that we asked the reporter of the issue as to *how* it was
found - that would be interesting information.

Noting which platforms are supported to which level and what level of test
coverage we have are the more important items in my view.

Tim.


On Wed, Apr 4, 2018 at 1:39 AM, Richard Levitte <levitte at openssl.org> wrote:

> While I totally agree with the direction Tim is taking on this, we
> need to remember that there's another condition as well: access to the
> platform in question, either directly by one of us, or through someone
> in the community.  Otherwise, we can have as many tests as we want, it
> still won't test *that* code (be it assembler or something else)
>
> In message <CAHEJ-S7o+ztC8gF3ZN_J7qoFPiCbxTOBYfrXr8AVK6s15Hd8C
> w at mail.gmail.com> on Tue, 03 Apr 2018 15:36:15 +0000, Tim Hudson <
> tjh at cryptsoft.com> said:
>
> tjh> And it should have a test - which has nothing to do with ASM and
> everything to do with improving
> tjh> test coverage.
> tjh>
> tjh> Bugs are bugs - and any form of meaningful test would have caught
> this.
> tjh>
> tjh> For the majority of the ASM code - the algorithm implementations we
> have tests that cover things
> tjh> in a decent manner.
> tjh>
> tjh> Improving tests is the solution - not whacking ASM code. Tests will
> catch issues across *all*
> tjh> implementations.
> tjh>
> tjh> Tim.
> tjh>
> tjh> On Tue, 3 Apr. 2018, 8:29 am Salz, Rich, <rsalz at akamai.com> wrote:
> tjh>
> tjh>  On 03/04/18 15:55, Salz, Rich wrote:
> tjh>  > This is one reason why keeping around old assembly code can have a
> cost. :(
> tjh>
> tjh>  Although in this case the code is <2 years old:
> tjh>
> tjh>  So? It's code that we do not test, and have not tested in years. And
> guess what? Critical CVE.
> tjh>
> tjh>  _______________________________________________
> tjh>  openssl-project mailing list
> tjh>  openssl-project at openssl.org
> tjh>  https://mta.openssl.org/mailman/listinfo/openssl-project
> tjh>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180404/b564778e/attachment-0001.html>

From paul.dale at oracle.com  Tue Apr  3 22:21:32 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Tue, 3 Apr 2018 15:21:32 -0700 (PDT)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180403.152838.1105373056478347916.levitte@openssl.org>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403.152838.1105373056478347916.levitte@openssl.org>
Message-ID: <67434254-8cae-4796-81bb-6f9b73638e80@default>

Richard wrote:

> (I'm tempted to try this with /dev/random only on Unix...  do I remember it right, that it blocks for a while after every 8 byte chunk on some Unixen?)

Many but not all /dev/random sources will block to fulfill the requested entropy if sufficient isn't in the gathering pool already.  (it's not quite that simple but that's the gist of it).  Some but not most  /dev/urandom sources will do the same.  Later kernels are better than older ones in general.  I'm not aware of a kernel that limits reads to 8 bytes at a time, although there usually is a single read size maximum.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: Richard Levitte [mailto:levitte at openssl.org] 
Sent: Tuesday, 3 April 2018 11:29 PM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] Entropy seeding the DRBG

In message <DA29A952-D1E7-44ED-8BE9-115E073A517B at akamai.com> on Tue, 3 Apr 2018 12:52:50 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> I had not realized that we just increased the "entropy"
rsalz> requirements by 50%, from 256 to 384. The original DRBG 
rsalz> submission that I did only required 128 bits.  I think that is 
rsalz> wrong, and I think the PR that did it (#5503) should be reverted.
rsalz> 
rsalz> I am concerned that we are trying to meet requirements that we 
rsalz> really don't have.  The original code was a huge improvement.
rsalz> 
rsalz> Requiring 384 bits of random seed is silly.  I think it is 
rsalz> ridiculous.  One way or another we HAVE to fix that before the 
rsalz> release.
rsalz> 
rsalz> Thoughts?

FYI, here's the magic number that lies behind this:

    : ; git grep RAND_DRBG_STRENGTH
    ...
    include/openssl/rand_drbg.h:# define RAND_DRBG_STRENGTH             256

The requirement change from 128 to 256 happened with this commit:

    commit 32bda2b2e4900308cb025020d8c8692e1d3c2ba9
    Author: Kurt Roeckx <kurt at roeckx.be>
    Date:   Sun Feb 18 19:16:13 2018 +0100
    
        Switch the DRBGs from AES-128-CTR to AES-256-CTR
        
        Reviewed-by: Dr. Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com>
        GH: #5401

And then there's this one, which did the added 50%:

    commit 2a70d65b99e1f2376be705d18bca88703b7e774a
    Author:     Kurt Roeckx <kurt at roeckx.be>
    AuthorDate: Sat Mar 3 23:19:03 2018 +0100
    Commit:     Kurt Roeckx <kurt at roeckx.be>
    CommitDate: Sun Apr 1 21:11:26 2018 +0200
    
        Make sure we use a nonce when a nonce is required
        
        If a nonce is required and the get_nonce callback is NULL, request 50%
        more entropy following NIST SP800-90Ar1 section 9.1.
        
        Reviewed-by: Dr. Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com>
        GH: #5503
    
Each of them seen by itself make sense.  The combined result, though, leaves me wondering...

(I'm tempted to try this with /dev/random only on Unix...  do I remember it right, that it blocks for a while after every 8 byte chunk on some Unixen?)

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-project mailing list
openssl-project at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

From Matthias.St.Pierre at ncp-e.com  Wed Apr  4 00:29:31 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Wed, 4 Apr 2018 02:29:31 +0200
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180403.152838.1105373056478347916.levitte@openssl.org>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403.152838.1105373056478347916.levitte@openssl.org>
Message-ID: <abc9c2ca-acf3-1418-38e4-03216641b0dc@ncp-e.com>

Since both pull requests mentioned by Richard were reviewed and approved
by me, I would to add a few remarks on those two pull requests:

Ad #5401:  Switch the DRBGs from AES-128-CTR to AES-256-CTR

> The requirement change from 128 to 256 happened with this commit:
>
>     commit 32bda2b2e4900308cb025020d8c8692e1d3c2ba9
>     Author: Kurt Roeckx <kurt at roeckx.be>
>     Date:   Sun Feb 18 19:16:13 2018 +0100
>     
>         Switch the DRBGs from AES-128-CTR to AES-256-CTR
>         
>         Reviewed-by: Dr. Matthias St. Pierre
<Matthias.St.Pierre at ncp-e.com>
>         GH: #5401

At first I was reluctant whether this increase was really necessary,
because AFAIK a security level of 128 bit is still considered sufficient
for most use cases. But Kurt argumented that OpenSSL supports encryption
algorithms with a security level of 256 bit in TLS (like AES-256-CTR),
so it is necessary that the random generator provides this level of
security. This sounded reasonable and after checking that the Linux
Random Number Generator was seeded with 256 bits of entropy
<http://www.chronox.de/lrng/doc/lrng.html>, I followed his arguments.

My original intention was to have the security strength configurable
with an option like --with-rand-strength=[128,192,256]. One could even
have chosen different defaults for different platforms. But this
approach was in conflict with Kurts argument above, stating that TLS
can't support 256 bit encryption algorithms if the underlying random
generator does not support this security level. So my TODO was dropped
in the above commit, see
<https://github.com/openssl/openssl/commit/32bda2b2e4900308cb025020d8c8692e1d3c2ba9#diff-f9d6c78326f4f4005a1795264fdd7d8dL22>.

IMHO there is no alternative to commit
32bda2b2e4900308cb025020d8c8692e1d3c2ba9, unless we say we only support
128 bit encryption algorithms.

Ad #5503:  Make sure we use a nonce when a nonce is required

> And then there's this one, which did the added 50%:
>
>     commit 2a70d65b99e1f2376be705d18bca88703b7e774a
>     Author:     Kurt Roeckx <kurt at roeckx.be>
>     AuthorDate: Sat Mar 3 23:19:03 2018 +0100
>     Commit:     Kurt Roeckx <kurt at roeckx.be>
>     CommitDate: Sun Apr 1 21:11:26 2018 +0200
>     
>         Make sure we use a nonce when a nonce is required
>         
>         If a nonce is required and the get_nonce callback is NULL,
request 50%
>         more entropy following NIST SP800-90Ar1 section 9.1.
>         
>         Reviewed-by: Dr. Matthias St. Pierre
<Matthias.St.Pierre at ncp-e.com>
>         GH: #5503

This pull request started initially when Kurt noticed that the NIST
standard requires the use of a nonce during instantiation, when a
derivation function is used, and that we were not providing
get_nonce()/cleanup_nonce() callbacks ourselves 
<https://github.com/openssl/openssl/pull/5461#discussion_r172030119>.

The use of the nonce is mandated by section 10.2.1.3.2 of Nist SP 800-90Ar1:

>    10.2.1.3.2 Instantiation When a Derivation Function is Used
>    When instantiation is performed using this method, the entropy
input may or may not have full entropy; in either case, a nonce is required

In Section 8.6.7 verious methods to obtain a nonce are discussed, see
also <https://github.com/openssl/openssl/pull/5503#issuecomment-371960392>:

>    8.6.7 Nonce
>
>    A nonce may be required in the construction of a seed during
instantiation in order to provide a security cushion to block certain
attacks. The nonce shall be either:
>      a. A value with at least (security_strength/2) bits of entropy, or
>      b. A value that is expected to repeat no more often than a
(security_strength/2)-bit random string would be expected to repeat.
>
>    A nonce may be composed of one (or more) of the following
components (other components may also be appropriate):
>
>    1. A random value that is generated anew for each nonce, using an
approved random bit generator.
>    2. A timestamp of sufficient resolution (detail) so that it is
different each time it is used.
>    3. A monotonically increasing sequence number, or
>    4. A combination of a timestamp and a monotonically increasing
sequence number, such that the sequence number is reset when and only
when the timestamp changes. For example, a timestamp may show the date
but not the time of day, so a sequence number is appended that will not
repeat during a particular day.
>
> For case 1 above, the random value could be acquired from the same
source and at the same time as the entropy input. In this case, the seed
could be considered to be constructed from an ?extra strong? entropy
input and the optional personalization string, where the entropy for the
entropy input is equal to or greater than (3/2 security_strength) bits.

I argued for using variant 4
<https://github.com/openssl/openssl/pull/5503#issuecomment-371960392>,
while Kurt favoured variant 1
<https://github.com/openssl/openssl/pull/5503#issuecomment-371954442>.
And he is still convinced that variant 1 is the best solution:

Am 03.04.2018 um 18:54 schrieb Kurt Roeckx:
> There is an alternative to that 50% extra, but it's not making sense
to me.

Contrary, to Kurt, I believe that the other variants are preferrable to
variant 1, because they are not so wasteful regarding entropy
requirements. So my proposal would be to implement the required
get_entropy()/cleanup_entropy() callbacks explicitely and go for variant
4. This would mean that not more than the minimum 256 bit of entropy is
needed. In theory solution 4 sounds simple: use a combination of a 64
bit timestamp and a 64 bit atomic counter as the 128 bit nonce. I say
"in theory", because I think of what a struggle we had with 64 bit
timers in https://github.com/openssl/openssl/pull/4757.

Somebody might argue that variant 3 is much simpler to implement. But as
far as I understood it, the nonce must be unique over all instantiations
accross multiple application instances. (I wouldn't be unhappy if
someone would prove me wrong here.)

Given the final beta stadium of 1.1.1, it is maybe the best solution for
the moment to revert pull request #5503 for 1.1.1 (i.e. don't care about
the nonce) and redo it correctly for the FIPS evaluation (post-1.1.1
resp. 1.2). As Rich already said multiple times: the random generator we
have now is much better already than anything we had before.

Matthias


TL;DR:  Here's the summary:

  - leave pull request #5401 as it is for release 1.1.1  (or state that
we only support 128 bit encryption)
  - repair pull request #5503, or better revert it for 1.1.1 and
reimplement it correctly for post-1.1.1 resp. 1.2







From rsalz at akamai.com  Wed Apr  4 00:59:05 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 4 Apr 2018 00:59:05 +0000
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <abc9c2ca-acf3-1418-38e4-03216641b0dc@ncp-e.com>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403.152838.1105373056478347916.levitte@openssl.org>
 <abc9c2ca-acf3-1418-38e4-03216641b0dc@ncp-e.com>
Message-ID: <72955566-0CBA-498A-9B20-791C663B7A84@akamai.com>

If you say that AES256 needs CSPRNG seeding with 256 bits, then why doesn't RSA 2048 keygen need seed to be seeded with 2048 bits?  I am not a cryptographer, but I do not agree with this argument
    algorithms with a security level of 256 bit in TLS (like AES-256-CTR),
    so it is necessary that the random generator provides this level of
    security.

But if it is true, an AES128-CTR DRBG is still sufficient for generating keys.  For the same reason that it is sufficient for generating Ed4418 or RSA2048 keys.

>    The use of the nonce is mandated by section 10.2.1.3.2 of Nist SP 800-90Ar1:
  
We are not going for FIPS validation here.  This might be a nice to have, but it is *NOT* a requirement for this release.  Especially if it puts the seeding requirement beyond the reach of some of our supported platforms.




From Matthias.St.Pierre at ncp-e.com  Wed Apr  4 06:35:06 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Wed, 4 Apr 2018 06:35:06 +0000
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <72955566-0CBA-498A-9B20-791C663B7A84@akamai.com>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403.152838.1105373056478347916.levitte@openssl.org>
 <abc9c2ca-acf3-1418-38e4-03216641b0dc@ncp-e.com>
 <72955566-0CBA-498A-9B20-791C663B7A84@akamai.com>
Message-ID: <14b81bf92c0c48198c5d401b84147acd@Ex13.ncp.local>

> -----Urspr?ngliche Nachricht-----
> Von: openssl-project <openssl-project-bounces at openssl.org> Im Auftrag von Salz, Rich
> Gesendet: Mittwoch, 4. April 2018 02:59
> An: openssl-project at openssl.org
> Betreff: Re: [openssl-project] Entropy seeding the DRBG
> 
> If you say that AES256 needs CSPRNG seeding with 256 bits, then why doesn't RSA 2048 keygen need seed to be seeded with 2048
> bits?  I am not a cryptographer, but I do not agree with this argument
>     algorithms with a security level of 256 bit in TLS (like AES-256-CTR),
>     so it is necessary that the random generator provides this level of
>     security.

Because it's not about the number of bits needed to store the key, but about the estimated amount of time to break it. According to https://csrc.nist.gov/csrc/media/projects/key-management/documents/transitions/transitioning_cryptoalgos_070209.pdf, the estimated security level of RSA 2048 is 112 bits:

> The security strength is measured in bits and is, basically, a measure of the difficulty of
> discovering the key. The understood security strength for each algorithm is listed in SP
> 800-57. For example, RSA using a key length of 1024 bits (i.e., 1024-bit RSA) has a
> security strength of 80 bits, as does 2-key Triple DES, while 2048-bit RSA and 3-key
> Triple DES have a security strength of 112 bits. See Table 2 in Part 1 of SP 800-57 for
> further security strength information.


> But if it is true, an AES128-CTR DRBG is still sufficient for generating keys.  For the same reason that it is sufficient for generating
> Ed4418 or RSA2048 keys.
> 
> >    The use of the nonce is mandated by section 10.2.1.3.2 of Nist SP 800-90Ar1:
> 
> We are not going for FIPS validation here.  This might be a nice to have, but it is *NOT* a requirement for this release.  Especially if it
> puts the seeding requirement beyond the reach of some of our supported platforms.
> 

I don't object to reverting it. After all, it takes only 88 bit to measure the age of the universe in nanoseconds, so 256 bits security should be fairly enough for the moment, even without a nonce.

Matthias



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180404/8686131d/attachment-0001.bin>

From levitte at openssl.org  Wed Apr  4 08:32:37 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 04 Apr 2018 10:32:37 +0200 (CEST)
Subject: [openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on
 SPARC/Solaris and maybe HPUX (#5867)
Message-ID: <20180404.103237.14102346559301117.levitte@openssl.org>

The attached report talks about CPP being required, but that's not the
intention.  Rather, this is an unnoticed mistake when cherry-picking
from master to 1.1.0.

The fix itself is easy (just add a line saying 'CPP=$(CC) -E'), and
that's not what I'm here to talk about, but rather how we want to act
in cases like this.  Do we make a new release?  Do we create an
official patch?  Do we make a link to the corrective github PR?
My own sense is that we should put up something, and it should be
visible on our download page and in our source archives.

Whatever we decide should become policy.

Cheers,
Richard
-------------- next part --------------
An embedded message was scrubbed...
From: thogard <notifications at github.com>
Subject: [openssl/openssl] 1.1.0h build issue on SPARC/Solaris and maybe HPUX (#5867)
Date: Wed, 04 Apr 2018 01:12:23 -0700
Size: 5438
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180404/4f0db3a6/attachment.mht>

From levitte at openssl.org  Wed Apr  4 08:34:44 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 04 Apr 2018 10:34:44 +0200 (CEST)
Subject: [openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on
 SPARC/Solaris and maybe HPUX (#5867)
In-Reply-To: <20180404.103237.14102346559301117.levitte@openssl.org>
References: <20180404.103237.14102346559301117.levitte@openssl.org>
Message-ID: <20180404.103444.2245256316027180187.levitte@openssl.org>

In message <20180404.103237.14102346559301117.levitte at openssl.org> on Wed, 04 Apr 2018 10:32:37 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:

levitte> The attached report talks about CPP being required, but that's not the
levitte> intention.  Rather, this is an unnoticed mistake when cherry-picking
levitte> from master to 1.1.0.
levitte> 
levitte> The fix itself is easy (just add a line saying 'CPP=$(CC) -E'), and
levitte> that's not what I'm here to talk about, but rather how we want to act
levitte> in cases like this.  Do we make a new release?  Do we create an
levitte> official patch?  Do we make a link to the corrective github PR?
levitte> My own sense is that we should put up something, and it should be
levitte> visible on our download page and in our source archives.

I forgot to add facts.  This mistakes affects assembler building on
IA64, Sparc and s390x:

    : ; find . -name '*.S'
    ./crypto/s390xcpuid.S
    ./crypto/md5/asm/md5-ia64.S
    ./crypto/aes/asm/aes-ia64.S
    ./crypto/sparccpuid.S
    ./crypto/bn/asm/sparcv8plus.S
    ./crypto/bn/asm/ia64.S
    ./crypto/bn/asm/sparcv8.S
    ./crypto/bn/asm/s390x.S
    ./crypto/ia64cpuid.S

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From openssl-users at dukhovni.org  Wed Apr  4 08:37:45 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 4 Apr 2018 04:37:45 -0400
Subject: [openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on
 SPARC/Solaris and maybe HPUX (#5867)
In-Reply-To: <20180404.103237.14102346559301117.levitte@openssl.org>
References: <20180404.103237.14102346559301117.levitte@openssl.org>
Message-ID: <24A045BB-3F05-40C0-B38D-C9CA3739E7A0@dukhovni.org>



> On Apr 4, 2018, at 4:32 AM, Richard Levitte <levitte at openssl.org> wrote:
> 
> The fix itself is easy (just add a line saying 'CPP=$(CC) -E'), and
> that's not what I'm here to talk about, but rather how we want to act
> in cases like this.  Do we make a new release?  Do we create an
> official patch?  Do we make a link to the corrective github PR?
> My own sense is that we should put up something, and it should be
> visible on our download page and in our source archives.
> 
> Whatever we decide should become policy.

I'd reissue an updated tarball as openssl-1.1.0h-u1.tar.gz,
where "u1" is "update 1".  This changes only a build bug,
not the code, so I'm tempted to keep the release name still
1.1.0h and not bump to 1.1.0i.d

-- 
	Viktor.


From matt at openssl.org  Wed Apr  4 08:38:26 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 4 Apr 2018 09:38:26 +0100
Subject: [openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on
 SPARC/Solaris and maybe HPUX (#5867)
In-Reply-To: <20180404.103237.14102346559301117.levitte@openssl.org>
References: <20180404.103237.14102346559301117.levitte@openssl.org>
Message-ID: <8e5b8aa9-c9f9-cbde-f030-6568a48eb6ae@openssl.org>

I'd say where we have introduced a regression in the latest release it
wouldn't hurt to have a "known issues" page, or similar, which links to
commits or other information about how to patch or work around an issue.

I see no reason to make a new release unless we think the issue is
sufficiently serious and/or affects large numbers of users.

Matt


On 04/04/18 09:32, Richard Levitte wrote:
> The attached report talks about CPP being required, but that's not the
> intention.  Rather, this is an unnoticed mistake when cherry-picking
> from master to 1.1.0.
> 
> The fix itself is easy (just add a line saying 'CPP=$(CC) -E'), and
> that's not what I'm here to talk about, but rather how we want to act
> in cases like this.  Do we make a new release?  Do we create an
> official patch?  Do we make a link to the corrective github PR?
> My own sense is that we should put up something, and it should be
> visible on our download page and in our source archives.
> 
> Whatever we decide should become policy.
> 
> Cheers,
> Richard
> 
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From levitte at openssl.org  Wed Apr  4 09:05:18 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 04 Apr 2018 11:05:18 +0200 (CEST)
Subject: [openssl-project] Fw: [openssl/openssl] 1.1.0h build issue on
 SPARC/Solaris and maybe HPUX (#5867)
In-Reply-To: <8e5b8aa9-c9f9-cbde-f030-6568a48eb6ae@openssl.org>
References: <20180404.103237.14102346559301117.levitte@openssl.org>
 <8e5b8aa9-c9f9-cbde-f030-6568a48eb6ae@openssl.org>
Message-ID: <20180404.110518.1681897354726677942.levitte@openssl.org>

I would like to have it more prominent.  I mean, yes, there should
probably be a known issues page, but I think that whatever we do, we
should have a line close to the one liking to the 1.1.0h tarball.  Why
send people chasing for it on other pages?

Also, some people are watching the source archive (https://ftp.openssl.org/)
directly, so the more I think about it, the more it makes sense to me
to place a patch there.  openssl-1.1.0h-errata.patch ?  That could
easily be linked into the list of downloadable things in
https://www.openssl.org/downloads/ with just a small tweak of the
script we use to generate that list.

In message <8e5b8aa9-c9f9-cbde-f030-6568a48eb6ae at openssl.org> on Wed, 4 Apr 2018 09:38:26 +0100, Matt Caswell <matt at openssl.org> said:

matt> I'd say where we have introduced a regression in the latest release it
matt> wouldn't hurt to have a "known issues" page, or similar, which links to
matt> commits or other information about how to patch or work around an issue.
matt> 
matt> I see no reason to make a new release unless we think the issue is
matt> sufficiently serious and/or affects large numbers of users.
matt> 
matt> Matt
matt> 
matt> 
matt> On 04/04/18 09:32, Richard Levitte wrote:
matt> > The attached report talks about CPP being required, but that's not the
matt> > intention.  Rather, this is an unnoticed mistake when cherry-picking
matt> > from master to 1.1.0.
matt> > 
matt> > The fix itself is easy (just add a line saying 'CPP=$(CC) -E'), and
matt> > that's not what I'm here to talk about, but rather how we want to act
matt> > in cases like this.  Do we make a new release?  Do we create an
matt> > official patch?  Do we make a link to the corrective github PR?
matt> > My own sense is that we should put up something, and it should be
matt> > visible on our download page and in our source archives.
matt> > 
matt> > Whatever we decide should become policy.
matt> > 
matt> > Cheers,
matt> > Richard
matt> > 
matt> > 
matt> > 
matt> > _______________________________________________
matt> > openssl-project mailing list
matt> > openssl-project at openssl.org
matt> > https://mta.openssl.org/mailman/listinfo/openssl-project
matt> > 
matt> _______________________________________________
matt> openssl-project mailing list
matt> openssl-project at openssl.org
matt> https://mta.openssl.org/mailman/listinfo/openssl-project
matt> 

From rsalz at akamai.com  Wed Apr  4 11:58:54 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 4 Apr 2018 11:58:54 +0000
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <14b81bf92c0c48198c5d401b84147acd@Ex13.ncp.local>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403.152838.1105373056478347916.levitte@openssl.org>
 <abc9c2ca-acf3-1418-38e4-03216641b0dc@ncp-e.com>
 <72955566-0CBA-498A-9B20-791C663B7A84@akamai.com>
 <14b81bf92c0c48198c5d401b84147acd@Ex13.ncp.local>
Message-ID: <122B3C36-21AD-4904-A692-351ADE567B8B@akamai.com>

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.




From levitte at openssl.org  Wed Apr  4 13:09:00 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 04 Apr 2018 15:09:00 +0200 (CEST)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <122B3C36-21AD-4904-A692-351ADE567B8B@akamai.com>
References: <72955566-0CBA-498A-9B20-791C663B7A84@akamai.com>
 <14b81bf92c0c48198c5d401b84147acd@Ex13.ncp.local>
 <122B3C36-21AD-4904-A692-351ADE567B8B@akamai.com>
Message-ID: <20180404.150900.406489426910014033.levitte@openssl.org>

In message <122B3C36-21AD-4904-A692-351ADE567B8B at akamai.com> on Wed, 4 Apr 2018 11:58:54 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> Is it expected that the number of bits of seed must equal the
rsalz> number of bits in the key strength?

It is expected that the number of bits of entropy in the seed (the VMS
function declares 4 bits of entropy per byte, considering the sources
it uses) equals a requirement, and it seems that the requirement is to
have the DRBG strength (which is measure in number of entropy bits)
match the number of bits of the block cipher used to generate the
randomness bits.  If I understand things correctly...  and that does
seem to match what's specified in SP800-90A r1.  I suggest a quick
study of table 3 in section 10 (Definitions for the CTR_DRBG), seen on
page 58 in https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-90ar1.pdf
Very specifically, there's the row with the title "Seed length
(seedlen = outlen + keylen)" that very clearly says 384 bits for
AES-256.

"Seed length" itself is defined in section 8:

    8.6.4 Seed Length 
    
    The minimum length of the seed depends on the DRBG mechanism and the
    security strength required by the consuming application, but shall be
    at least the number of bits of entropy required. See the tables in
    Section 10.

rsalz> But at any rate, raising the seed size to 256 seems mildly
rsalz> tolerable, although I would prefer to keep it at 128.  Raising
rsalz> it to 384 is wrong.

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.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Wed Apr  4 13:21:40 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 4 Apr 2018 13:21:40 +0000
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180404.150900.406489426910014033.levitte@openssl.org>
References: <72955566-0CBA-498A-9B20-791C663B7A84@akamai.com>
 <14b81bf92c0c48198c5d401b84147acd@Ex13.ncp.local>
 <122B3C36-21AD-4904-A692-351ADE567B8B@akamai.com>
 <20180404.150900.406489426910014033.levitte@openssl.org>
Message-ID: <BD255FA3-E970-4624-802E-524C6CDEC12C@akamai.com>

>    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).



From Matthias.St.Pierre at ncp-e.com  Wed Apr  4 13:50:41 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Wed, 4 Apr 2018 13:50:41 +0000
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180404.150900.406489426910014033.levitte@openssl.org>
References: <72955566-0CBA-498A-9B20-791C663B7A84@akamai.com>
 <14b81bf92c0c48198c5d401b84147acd@Ex13.ncp.local>
 <122B3C36-21AD-4904-A692-351ADE567B8B@akamai.com>
 <20180404.150900.406489426910014033.levitte@openssl.org>
Message-ID: <074d3a68bd6f43068ba8b40ecae96571@Ex13.ncp.local>

The internal state of the CTR-DRBG consists of a key K and a counter V (see figure 11 on page 48, which is the page before table 3). This is the reason why it requires bits_of(K) + bits_of(V) = keysize + blocksize = 256 + 128 = 384 bits to initialize the internal state of the DRBG. 

But the seedlen (in bits) *does not* in general coincide with the security_strength! This is only in the case when _no_ derivation function is used! See the aforementioned table 3 on page 49:

	If a derivation function is not used:
		Minimum entropy input length:      	seedlen
		(min _length = blocklen + keylen)	

		
But we are in the case when a derivation function is used. Here only 'security_strength' (= 256) bits of entropy are required.
		
	If a derivation function is used:      
		Minimum entropy input length:           security_strength
		(min _length)

These bits are 'stretched out' to seed_length (=384) bits by the "derivation function", which is essentially an aes-ctr bit stream. Or, to be more precise: if we provide a large buffer of low entropy input, then this low entropy input will be condensed, stirred, and spread out equally over the 384 bits of the initial state by the derivation function.

Matthias

> -----Urspr?ngliche Nachricht-----
> Von: openssl-project <openssl-project-bounces at openssl.org> Im Auftrag von Richard Levitte
> Gesendet: Mittwoch, 4. April 2018 15:09
> An: openssl-project at openssl.org
> Betreff: Re: [openssl-project] Entropy seeding the DRBG
> 
> In message <122B3C36-21AD-4904-A692-351ADE567B8B at akamai.com> on Wed, 4 Apr 2018 11:58:54 +0000, "Salz, Rich"
> <rsalz at akamai.com> said:
> 
> rsalz> Is it expected that the number of bits of seed must equal the
> rsalz> number of bits in the key strength?
> 
> It is expected that the number of bits of entropy in the seed (the VMS
> function declares 4 bits of entropy per byte, considering the sources
> it uses) equals a requirement, and it seems that the requirement is to
> have the DRBG strength (which is measure in number of entropy bits)
> match the number of bits of the block cipher used to generate the
> randomness bits.  If I understand things correctly...  and that does
> seem to match what's specified in SP800-90A r1.  I suggest a quick
> study of table 3 in section 10 (Definitions for the CTR_DRBG), seen on
> page 58 in https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-90ar1.pdf
> Very specifically, there's the row with the title "Seed length
> (seedlen = outlen + keylen)" that very clearly says 384 bits for
> AES-256.
> 
> "Seed length" itself is defined in section 8:
> 
>     8.6.4 Seed Length
> 
>     The minimum length of the seed depends on the DRBG mechanism and the
>     security strength required by the consuming application, but shall be
>     at least the number of bits of entropy required. See the tables in
>     Section 10.
> 
> rsalz> But at any rate, raising the seed size to 256 seems mildly
> rsalz> tolerable, although I would prefer to keep it at 128.  Raising
> rsalz> it to 384 is wrong.
> 
> 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.
> 
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180404/dce0ed74/attachment.bin>

From matt at openssl.org  Wed Apr  4 15:07:15 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 4 Apr 2018 16:07:15 +0100
Subject: [openssl-project] Monthly Status Report (March)
Message-ID: <ab6d3b53-2ee2-f716-15f2-a5e1c7e81166@openssl.org>

As well as normal reviews, responding to user queries, wiki user
requests, OMC business, handling security reports, etc., key activities
this month:

- Performed the 1.1.1 beta 1 (pre-3) release
- Performed a security release for 1.1.0 and 1.0.2
- Carried out a number of different tasks around the re-licensing,
reviewing and investigating old commits and rewriting some where required
- Implemented the TLSv1.3 anti-replay mechanism
- Fixed numerous "no-" compilation options
- Investigated and fixed a text canonicalisation bug in CMS
- Major overhaul of the genpkey documentation which was very out of date
- Investigated and developed a fix for SSL config problems where engines
cannot be loaded prior to the initialisation of libssl
- Implemented changes to tolerate a Certificate using a non-supported
group on the server side.
- Fixed a bug where generating a key for certain unusual EC curves
failed due to an attempt to write out the ASN.1 with a bad OID
- Fixed a travis problem where builds were failing due to excessive log size
- Fixed various problems with the ca application
- Implemented a capability to import "raw" keys for various algorithms
via EVP (e.g. X25519/Ed25519/X448/Ed448 etc).
- Fixed a TLSv1.3 server side session caching issue
- Implemented a new ciphersuite configuration approach for TLSv1.3
- Updated for support of TLSv1.3 draft-26
- Stopped ossl_shim from negotiating TLSv1.3 which was causing travis
failures
- Fixed some issues with SSL_stateless() in order to give more
information to callers
- Implemented fixes for PSK support to enable old-style PSKs to be used
in TLSv1.3
- Completed and committed support for X448/Ed448
- Performed some interoperability testing for Ed25519/Ed448


Matt

From rsalz at akamai.com  Thu Apr  5 16:27:13 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 5 Apr 2018 16:27:13 +0000
Subject: [openssl-project] Vote results
Message-ID: <1E2ECC54-1349-4233-947C-5C922334C610@akamai.com>

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


From openssl-users at dukhovni.org  Thu Apr  5 16:55:30 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 5 Apr 2018 12:55:30 -0400
Subject: [openssl-project] Kudos to Matt on the genpkey doc rewrite
Message-ID: <7F8EB66A-A450-4E28-BCA6-E66893CD46FD@dukhovni.org>


I'd like to thank Matt for going above and beyond the immediate issue raised (documenting the EdDSA algorithm options) and thoroughly updating the genpkey(1) manpage, reviewing the code and fixing bugs, etc.

This is the kind of thoroughness that it takes to pay down past technical debt and prove that the project is worthy of the recognition awarded through the Levchin prize.  Thanks Matt.  Great work!

-- 
	Viktor.


From rsalz at akamai.com  Thu Apr  5 17:18:13 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 5 Apr 2018 17:18:13 +0000
Subject: [openssl-project] build broken?
Message-ID: <F3E1C9D0-51F2-4DEA-84A6-545D1DF0172A@akamai.com>

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
CONF_F_NCONF_LOAD_FP:114:NCONF_load_fp
CONF_F_NCONF_NEW:111:NCONF_new
CONF_F_PROCESS_INCLUDE:116:process_include
-CONF_F_SSL_MODULE_INIT:122:ssl_module_init
+CONF_F_SSL_MODULE_INIT:123:ssl_module_init
CONF_F_STR_COPY:101:str_copy
CRYPTO_F_CRYPTO_DUP_EX_DATA:110:CRYPTO_dup_ex_data
CRYPTO_F_CRYPTO_FREE_EX_DATA:111:CRYPTO_free_ex_data
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180405/762ff3cf/attachment.html>

From levitte at openssl.org  Thu Apr  5 19:12:10 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 05 Apr 2018 21:12:10 +0200 (CEST)
Subject: [openssl-project] build broken?
In-Reply-To: <F3E1C9D0-51F2-4DEA-84A6-545D1DF0172A@akamai.com>
References: <F3E1C9D0-51F2-4DEA-84A6-545D1DF0172A@akamai.com>
Message-ID: <20180405.211210.1630954715962635634.levitte@openssl.org>

So, uhmmm, why didn't you make a PR from this?

In message <F3E1C9D0-51F2-4DEA-84A6-545D1DF0172A at akamai.com> on Thu, 5 Apr 2018 17:18:13 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> Making update
rsalz> CONF function code 122 collision at CONF_F_SSL_MODULE_INIT
rsalz> 
rsalz> diff --git a/crypto/err/openssl.txt b/crypto/err/openssl.txt
rsalz> index d1cc039..de3dacc 100644
rsalz> --- a/crypto/err/openssl.txt
rsalz> +++ b/crypto/err/openssl.txt
rsalz> @@ -335,7 +335,7 @@ CONF_F_NCONF_LOAD_BIO:110:NCONF_load_bio
rsalz> CONF_F_NCONF_LOAD_FP:114:NCONF_load_fp
rsalz> CONF_F_NCONF_NEW:111:NCONF_new
rsalz> CONF_F_PROCESS_INCLUDE:116:process_include
rsalz> -CONF_F_SSL_MODULE_INIT:122:ssl_module_init
rsalz> +CONF_F_SSL_MODULE_INIT:123:ssl_module_init
rsalz> CONF_F_STR_COPY:101:str_copy
rsalz> CRYPTO_F_CRYPTO_DUP_EX_DATA:110:CRYPTO_dup_ex_data
rsalz> CRYPTO_F_CRYPTO_FREE_EX_DATA:111:CRYPTO_free_ex_data

From rsalz at akamai.com  Thu Apr  5 19:13:21 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 5 Apr 2018 19:13:21 +0000
Subject: [openssl-project] build broken?
In-Reply-To: <20180405.211210.1630954715962635634.levitte@openssl.org>
References: <F3E1C9D0-51F2-4DEA-84A6-545D1DF0172A@akamai.com>
 <20180405.211210.1630954715962635634.levitte@openssl.org>
Message-ID: <CE0AC15D-CCA3-4781-92A9-A821741A22D4@akamai.com>

I thought someone else would beat me to it.  Like, maybe, the person who broke things :)

But the fix is part of 5886 which you approved and I am merging now ...

?On 4/5/18, 3:12 PM, "Richard Levitte" <levitte at openssl.org> wrote:

    So, uhmmm, why didn't you make a PR from this?
    
    In message <F3E1C9D0-51F2-4DEA-84A6-545D1DF0172A at akamai.com> on Thu, 5 Apr 2018 17:18:13 +0000, "Salz, Rich" <rsalz at akamai.com> said:
    
    rsalz> Making update
    rsalz> CONF function code 122 collision at CONF_F_SSL_MODULE_INIT
    rsalz> 
    rsalz> diff --git a/crypto/err/openssl.txt b/crypto/err/openssl.txt
    rsalz> index d1cc039..de3dacc 100644
    rsalz> --- a/crypto/err/openssl.txt
    rsalz> +++ b/crypto/err/openssl.txt
    rsalz> @@ -335,7 +335,7 @@ CONF_F_NCONF_LOAD_BIO:110:NCONF_load_bio
    rsalz> CONF_F_NCONF_LOAD_FP:114:NCONF_load_fp
    rsalz> CONF_F_NCONF_NEW:111:NCONF_new
    rsalz> CONF_F_PROCESS_INCLUDE:116:process_include
    rsalz> -CONF_F_SSL_MODULE_INIT:122:ssl_module_init
    rsalz> +CONF_F_SSL_MODULE_INIT:123:ssl_module_init
    rsalz> CONF_F_STR_COPY:101:str_copy
    rsalz> CRYPTO_F_CRYPTO_DUP_EX_DATA:110:CRYPTO_dup_ex_data
    rsalz> CRYPTO_F_CRYPTO_FREE_EX_DATA:111:CRYPTO_free_ex_data
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From matt at openssl.org  Fri Apr  6 07:46:55 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 6 Apr 2018 08:46:55 +0100
Subject: [openssl-project] build broken?
In-Reply-To: <CE0AC15D-CCA3-4781-92A9-A821741A22D4@akamai.com>
References: <F3E1C9D0-51F2-4DEA-84A6-545D1DF0172A@akamai.com>
 <20180405.211210.1630954715962635634.levitte@openssl.org>
 <CE0AC15D-CCA3-4781-92A9-A821741A22D4@akamai.com>
Message-ID: <b365d52f-1a54-bc35-4eef-9ab00b58d284@openssl.org>



On 05/04/18 20:13, Salz, Rich wrote:
> I thought someone else would beat me to it.  Like, maybe, the person who broke things :)
> 
> But the fix is part of 5886 which you approved and I am merging now ...

Oops! Sorry :-)

The fix needs to go into 1.1.0 too to keep the numbers consistent:

https://github.com/openssl/openssl/pull/5892

Matt


> 
> ?On 4/5/18, 3:12 PM, "Richard Levitte" <levitte at openssl.org> wrote:
> 
>     So, uhmmm, why didn't you make a PR from this?
>     
>     In message <F3E1C9D0-51F2-4DEA-84A6-545D1DF0172A at akamai.com> on Thu, 5 Apr 2018 17:18:13 +0000, "Salz, Rich" <rsalz at akamai.com> said:
>     
>     rsalz> Making update
>     rsalz> CONF function code 122 collision at CONF_F_SSL_MODULE_INIT
>     rsalz> 
>     rsalz> diff --git a/crypto/err/openssl.txt b/crypto/err/openssl.txt
>     rsalz> index d1cc039..de3dacc 100644
>     rsalz> --- a/crypto/err/openssl.txt
>     rsalz> +++ b/crypto/err/openssl.txt
>     rsalz> @@ -335,7 +335,7 @@ CONF_F_NCONF_LOAD_BIO:110:NCONF_load_bio
>     rsalz> CONF_F_NCONF_LOAD_FP:114:NCONF_load_fp
>     rsalz> CONF_F_NCONF_NEW:111:NCONF_new
>     rsalz> CONF_F_PROCESS_INCLUDE:116:process_include
>     rsalz> -CONF_F_SSL_MODULE_INIT:122:ssl_module_init
>     rsalz> +CONF_F_SSL_MODULE_INIT:123:ssl_module_init
>     rsalz> CONF_F_STR_COPY:101:str_copy
>     rsalz> CRYPTO_F_CRYPTO_DUP_EX_DATA:110:CRYPTO_dup_ex_data
>     rsalz> CRYPTO_F_CRYPTO_FREE_EX_DATA:111:CRYPTO_free_ex_data
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>     
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From appro at openssl.org  Fri Apr  6 14:23:02 2018
From: appro at openssl.org (Andy Polyakov)
Date: Fri, 6 Apr 2018 16:23:02 +0200
Subject: [openssl-project] FW: April Crypto Bulletin from Cryptosense
In-Reply-To: <93B32B79-18B9-4B0E-8D63-6161AE28166F@akamai.com>
References: <6123dc021d88a3dbe3c81eeba.4a7a7251ad.20180403132421.0620ecd98c.f54bee76@mail179.wdc02.mcdlv.net>
 <93B32B79-18B9-4B0E-8D63-6161AE28166F@akamai.com>
Message-ID: <20709408-351c-1da3-8657-005443446b6d@openssl.org>

> This is one reason why keeping around old assembly code can have a cost. :(
> 
> https://github.com/openssl/openssl/pull/5320

There is nothing I can add to what I've already said. To quote myself.
"None of what I say means that everything *has to* be kept, but as
already said, some of them serve meaningful purpose..."

Well, I also said that "I'm *not* saying that bit-rot is not a concern,
only that it's not really assembly-specific." And I can probably add
something here, in addition to already mentioned example of legacy code
relying on formally undefined or implementation-specific behaviour. It's
not actually that uncommon that *new* C code is committed[!!!]
"bit-rotten". So one can *just as well* say that supporting another
operating system has a cost, and so does using another compiler... Why
not get "angry" about that? What's the difference really? Relevant
question is what's more expensive, supporting multiple compilers?
multiple OSes? multiple assembly? To give a "tangible" example in the
context of forwarded message [that mentions PA-RISC assembly code.] How
long time did it take me to figure out what's wrong and verify that
problem is resolved? Couple of hours (mostly because old systems are
sloooow and it takes time to compile our stuff). How long time did it
take me to resolve HP-UX problems triggered by report on 20th of March?
I'm presumably[!] done by about now... To summarize, one can make same
argument about multiple things, yet we do them. Why? Because it works to
our advantage [directly or indirectly]...

From kaduk at mit.edu  Fri Apr  6 17:05:43 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Fri, 6 Apr 2018 12:05:43 -0500
Subject: [openssl-project] FW: April Crypto Bulletin from Cryptosense
In-Reply-To: <20709408-351c-1da3-8657-005443446b6d@openssl.org>
References: <6123dc021d88a3dbe3c81eeba.4a7a7251ad.20180403132421.0620ecd98c.f54bee76@mail179.wdc02.mcdlv.net>
 <93B32B79-18B9-4B0E-8D63-6161AE28166F@akamai.com>
 <20709408-351c-1da3-8657-005443446b6d@openssl.org>
Message-ID: <20180406170540.GK80088@mit.edu>

On Fri, Apr 06, 2018 at 04:23:02PM +0200, Andy Polyakov wrote:
> > This is one reason why keeping around old assembly code can have a cost. :(
> > 
> > https://github.com/openssl/openssl/pull/5320
> 
> There is nothing I can add to what I've already said. To quote myself.
> "None of what I say means that everything *has to* be kept, but as
> already said, some of them serve meaningful purpose..."
> 
> Well, I also said that "I'm *not* saying that bit-rot is not a concern,
> only that it's not really assembly-specific." And I can probably add
> something here, in addition to already mentioned example of legacy code
> relying on formally undefined or implementation-specific behaviour. It's
> not actually that uncommon that *new* C code is committed[!!!]
> "bit-rotten". So one can *just as well* say that supporting another
> operating system has a cost, and so does using another compiler... Why
> not get "angry" about that? What's the difference really? Relevant

Yes, supporting another operating system has a cost!
At risk of drawing Richard's ire, if we did not intend to support
(e.g.) VMS, we might have been able to get away with not writing our
own custom build system in favor of some "industry standard".
Supporting non-POSIX systems (e.g., Windows) also adds overhead in
how we implement many of our interfaces (file handling, thread
handling, locking, randomness, etc.).

I personally prefer a more conservative/restrictive approach than
the historical trend, and probably also more conservative than the
average of the team.  This is presumably shaped by my personal
experiences and career trajectory, and I understand that others'
path are different and so they will have different, but still valid,
preferences.  We as a team are charged with weighing the tradeoff of
supporting an additional platform against the burden of supporting
it and the risks against our ability to continue supporting it.  For
example, in this modern world where properly supporting a platform
basically does require some assembly code, for crypto-relevant
timing considerations, if only one person understands and will
support that assembly code, that is a risk.  Perhaps it's enough of
a risk to make officially supporting that platform a bad idea;
perhaps not -- it's just one factor that we must, as a whole, weigh
and consider.
Removing platform-specific assembly when not needed for security
would seem to reduce the risk, and presumably improve the
maintainability of the software as a whole.  But I don't see a good
way to not have these decisions all be made on a case-by-case basis.

-Ben

From levitte at openssl.org  Sat Apr  7 12:10:06 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 07 Apr 2018 14:10:06 +0200 (CEST)
Subject: [openssl-project] FW: April Crypto Bulletin from Cryptosense
In-Reply-To: <20180406170540.GK80088@mit.edu>
References: <93B32B79-18B9-4B0E-8D63-6161AE28166F@akamai.com>
 <20709408-351c-1da3-8657-005443446b6d@openssl.org>
 <20180406170540.GK80088@mit.edu>
Message-ID: <20180407.141006.710149562682082880.levitte@openssl.org>

In message <20180406170540.GK80088 at mit.edu> on Fri, 6 Apr 2018 12:05:43 -0500, Benjamin Kaduk <kaduk at mit.edu> said:

kaduk> On Fri, Apr 06, 2018 at 04:23:02PM +0200, Andy Polyakov wrote:
kaduk> > > This is one reason why keeping around old assembly code can have a cost. :(
kaduk> > > 
kaduk> > > https://github.com/openssl/openssl/pull/5320
kaduk> > 
kaduk> > There is nothing I can add to what I've already said. To quote myself.
kaduk> > "None of what I say means that everything *has to* be kept, but as
kaduk> > already said, some of them serve meaningful purpose..."
kaduk> > 
kaduk> > Well, I also said that "I'm *not* saying that bit-rot is not a concern,
kaduk> > only that it's not really assembly-specific." And I can probably add
kaduk> > something here, in addition to already mentioned example of legacy code
kaduk> > relying on formally undefined or implementation-specific behaviour. It's
kaduk> > not actually that uncommon that *new* C code is committed[!!!]
kaduk> > "bit-rotten". So one can *just as well* say that supporting another
kaduk> > operating system has a cost, and so does using another compiler... Why
kaduk> > not get "angry" about that? What's the difference really? Relevant
kaduk> 
kaduk> Yes, supporting another operating system has a cost!
kaduk> At risk of drawing Richard's ire, if we did not intend to support
kaduk> (e.g.) VMS, we might have been able to get away with not writing our
kaduk> own custom build system in favor of some "industry standard".
kaduk> Supporting non-POSIX systems (e.g., Windows) also adds overhead in
kaduk> how we implement many of our interfaces (file handling, thread
kaduk> handling, locking, randomness, etc.).

I can channel my ire, thank you ;-)

But speaking of these things, I somewhat understand where you're
coming from, and somehow, this makes me think of the way the OpenBSD
folks do things, starting with something that's purely and entirely
for OpenBSD, and then expanding it with platform ports, and that's
actually a line of thought I could live with... BUT, and yeah, that's
a bit BUT...  our layering principles currently suck enormously, and
that also adds to the total cost of maintaining stuff.  Basically, we
have a number of platform specific stuff injected in the code a little
here and there, when we really should make the effort of putting
together an architecture independent layer that anyone would much more
easily write an implementation of for whatever new platform that comes
around, and could even come as a separate porting package that someone
else provides.

In a way, the new build system that I put together is exactly meant to
be a thing that makes it easier to port to other platforms, and at
least try to make it so that port could be delivered as a separate
package.  That was always my goal, and that was also the reason I
decided to write it in perl, 'cause that language is already ported to
all kinds of platforms like no other scripting language.  Not even
python, which is actually quite well ported, reaches as far.
(auto* tools are an abomination to try to port to anything that
doesn't look like a POSIX environment.  I tried, about 20 years ago.
Cmake, which was otherwise a strong candidate i my book, has presented
some challenges to port to VMS as well...  others have tried.  I don't
know so many others that have become popular enough to be considered
"industry standards")

But going back to what I said higher up, I very much wish we had an
actual consistent architecture agnostic layer.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Sat Apr  7 14:15:51 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 7 Apr 2018 14:15:51 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <openssl/openssl/pull/5904@github.com>
References: <openssl/openssl/pull/5904@github.com>
Message-ID: <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>

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 <notifications at github.com>
Reply-To: openssl/openssl <reply+006fe294b88b1b00f712afbd9c8b598fbacf36e3d1ffef7092cf0000000116e06f2192a169ce129bc983 at reply.github.com>
Date: Saturday, April 7, 2018 at 7:36 AM
To: openssl/openssl <openssl at noreply.github.com>
Cc: Subscribed <subscribed at noreply.github.com>
Subject: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)


Currently, the VMS version of rand_pool_acquire_entropy() delivers 256
bits of entropy. The DRBG using AES-256-CTR and wanting 50% extra
bits for the nonce demands 384 bits of entropy. Obviously, this makes
anything random related to fail on VMS.

The solution for now, until we get the VMS rand_pool_acquire_entropy()
to deliver more entropy, is to lower the bar for VMS specifically,
i.e. making the default scrambling cipher AES-128-CTR instead of
AES-256-CTR.

Fixes #5849<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_issues_5849&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kyk90HbC75s2XWKsF3IXUFtJ3WaC7ro5Lsuohk8GqXc&s=wHYr3-v_LNVUlhpP6-Ra05SuFf41rUBkdz1wSVF3kwE&e=>

________________________________
You can view, comment on, or merge this pull request online at:

  https://github.com/openssl/openssl/pull/5904<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_5904&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kyk90HbC75s2XWKsF3IXUFtJ3WaC7ro5Lsuohk8GqXc&s=HErxLwNbZRguCm9RhoMqXHQ83nOOsvDQF9bAeieem8c&e=>

Commit Summary

  *   VMS: lower the entropy demand for this platform specifically

File Changes

  *   M include/openssl/rand_drbg.h<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_5904_files-23diff-2D0&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kyk90HbC75s2XWKsF3IXUFtJ3WaC7ro5Lsuohk8GqXc&s=IQl76CU_ObYAV_UB1YKDT6NjB3ayBFQnn1rWI0NlCMo&e=> (10)

Patch Links:

  *   https://github.com/openssl/openssl/pull/5904.patch<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_5904.patch&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kyk90HbC75s2XWKsF3IXUFtJ3WaC7ro5Lsuohk8GqXc&s=d7Q6NQV7uD6tEaQ-41PC7_UwtnuP7NwdDvO-FvlZtI4&e=>
  *   https://github.com/openssl/openssl/pull/5904.diff<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_5904.diff&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kyk90HbC75s2XWKsF3IXUFtJ3WaC7ro5Lsuohk8GqXc&s=P8cE-AGU9epcphblbrEonkqMykuJYjiRmH3drj3HD1Y&e=>

?
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_5904&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kyk90HbC75s2XWKsF3IXUFtJ3WaC7ro5Lsuohk8GqXc&s=HErxLwNbZRguCm9RhoMqXHQ83nOOsvDQF9bAeieem8c&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AG-5FilJ8SNbUkW80n2jdBuhC8Nn2N1eZeks5tmKShgaJpZM4TLC-5Fs&d=DwMCaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=kyk90HbC75s2XWKsF3IXUFtJ3WaC7ro5Lsuohk8GqXc&s=O4wdZANToOQhowJYc_HwuOrCQPqe5PY7oRRvd2xAtFM&e=>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180407/0e993894/attachment-0001.html>

From levitte at openssl.org  Sat Apr  7 14:58:06 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 07 Apr 2018 16:58:06 +0200 (CEST)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403165409.GA22094@roeckx.be>
 <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>
Message-ID: <20180407.165806.463561558996899206.levitte@openssl.org>

In message <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7 at akamai.com> on Tue, 3 Apr 2018 16:58:17 +0000, "Salz, Rich" <rsalz at akamai.com> said:

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

Instantiating is exactly the problem.  The VMS
rand_pool_acquire_entropy() currently generates 256 bits of entropy on
each call.  No more, no less.  And that's at an estimated 4 bits of
entropy per byte, and estimation that's from long ago.  Either way,
because instantiation demands more than 256 bits, the whole RNG breaks
down, and everything related to it in some way along with it.  In
other words, OpenSSL on VMS dies.

rsalz> True.  And now we're finding that VMS won't work.  And I bet
rsalz> there are other systems that will also find this amount
rsalz> excessive.

I'm thinking that for any platform that can support that, I don't see
a problem, at all.

So the current short term solution for this is to simply default to
AES-128-CTR instead of AES-256-CTR, specifically on VMS, which is
currently sitting in PR#5904.  It seems like the option to make
everyone happy, and everyone ends up with a better randomness
implementation either way (compared to OpenSSL 1.1.0 and older).

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.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Sat Apr  7 14:59:55 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 07 Apr 2018 16:59:55 +0200 (CEST)
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
Message-ID: <20180407.165955.1814164569110811454.levitte@openssl.org>

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....

Cheers,
Richard

In message <116A311C-48B3-4181-9E68-B2FCC8D2D06E at akamai.com> on Sat, 7 Apr 2018 14:15:51 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> I would like to see this put on hold until we fix the ?now requires 50% more random seeding? issue.
rsalz> 
rsalz> What should I do to force that issue?
rsalz> 
rsalz> From: Richard Levitte <notifications at github.com>
rsalz> Reply-To: openssl/openssl
rsalz> <reply+006fe294b88b1b00f712afbd9c8b598fbacf36e3d1ffef7092cf0000000116e06f2192a169ce129bc983 at reply.github.com>
rsalz> 
rsalz> Date: Saturday, April 7, 2018 at 7:36 AM
rsalz> To: openssl/openssl <openssl at noreply.github.com>
rsalz> Cc: Subscribed <subscribed at noreply.github.com>
rsalz> Subject: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)
rsalz> 
rsalz> Currently, the VMS version of rand_pool_acquire_entropy() delivers 256
rsalz> bits of entropy. The DRBG using AES-256-CTR and wanting 50% extra
rsalz> bits for the nonce demands 384 bits of entropy. Obviously, this makes
rsalz> anything random related to fail on VMS.
rsalz> 
rsalz> The solution for now, until we get the VMS rand_pool_acquire_entropy()
rsalz> to deliver more entropy, is to lower the bar for VMS specifically,
rsalz> i.e. making the default scrambling cipher AES-128-CTR instead of
rsalz> AES-256-CTR.
rsalz> 
rsalz> Fixes #5849
rsalz> 
rsalz> ---------------------------------------------------------------------------------------------------
rsalz> 
rsalz> You can view, comment on, or merge this pull request online at:
rsalz> 
rsalz> https://github.com/openssl/openssl/pull/5904
rsalz> 
rsalz> Commit Summary
rsalz> 
rsalz> * VMS: lower the entropy demand for this platform specifically
rsalz> 
rsalz> File Changes
rsalz> 
rsalz> * M include/openssl/rand_drbg.h (10)
rsalz> 
rsalz> Patch Links:
rsalz> 
rsalz> * https://github.com/openssl/openssl/pull/5904.patch
rsalz> 
rsalz> * https://github.com/openssl/openssl/pull/5904.diff
rsalz> 
rsalz> ?
rsalz> You are receiving this because you are subscribed to this thread.
rsalz> Reply to this email directly, view it on GitHub, or mute the thread.
rsalz> 

From kurt at roeckx.be  Sat Apr  7 15:46:50 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 7 Apr 2018 17:46:50 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
Message-ID: <20180407154649.GA12191@roeckx.be>

On Sat, Apr 07, 2018 at 02:15:51PM +0000, Salz, Rich wrote:
> 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?

NIST SP800-90A rev1 section 8.6.7 has:
| A nonce may be required in the construction of a seed during
| instantiation in order to provide a security cushion to block
| certain attacks. The nonce shall be either:
|
| a. A value with at least (security_strength/2) bits of entropy, or
| b. A value that is expected to repeat no more often than a
| (security_strength/2)-bit random string would be expected to repeat.
|
| Each nonce shall be unique to the cryptographic module in which
| instantiation is performed, but need not be secret. When used, the
| nonce shall be considered to be a critical security parameter.
|
| A nonce may be composed of one (or more) of the following
| components (other components may also be appropriate):
| 1. A random value that is generated anew for each nonce, using an
| approved random bit generator.
| 2. A timestamp of sufficient resolution (detail) so that it is
| different each time it is used.
| 3. A monotonically increasing sequence number, or
| 4. A combination of a timestamp and a monotonically increasing
| sequence number, such that the sequence number is reset when and
| only when the timestamp changes. For example, a timestamp may show
| the date but not the time of day, so a sequence number is appended
| that will not repeat during a particular day.
|
| For case 1 above, the random value could be acquired from the same
| source and at the same time as the entropy input. In this case,
| the seed could be considered to be constructed from an
| ?extra strong? entropy input and the optional personalization
| string, where the entropy for the entropy input is equal to or
| greater than (3/2 security_strength) bits.
|
| For case 2 above, the timestamp must be trusted. A trusted
| timestamp is generated and signed by an entity that is trusted
| to provide accurate time information.

Case 1 requires an approved random bit generator, which we don't
have by default.

Case 2 requires the timestamp to be trusted. I think that applies
to case 4 too. This is also something we can't do by default.

I think case 3 requires us keep a counter even after restarting
the application, which seems unlikely that we will implement it.

So by default we can't do any of them. But you can argue that we
can do case 1, 2 and 4 close enough. Case 1 is what we do now.

I think we can do case 2 with something like gettimeofday() or
clock_gettime() which I think provide plenty of resolution
that it's unlikely to repeat.

You can combine that with a counter to get case 4 if you really
wanted.

All you have to do is implement a get_nonce() function and set it
by default. You can keep the behaviour that if no get_nonce function
is set that it increases the entropy requirement.


Kurt

that 

From kurt at roeckx.be  Sat Apr  7 16:00:32 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 7 Apr 2018 18:00:32 +0200
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180407.165806.463561558996899206.levitte@openssl.org>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403165409.GA22094@roeckx.be>
 <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>
 <20180407.165806.463561558996899206.levitte@openssl.org>
Message-ID: <20180407160031.GB12191@roeckx.be>

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


From rsalz at akamai.com  Sat Apr  7 16:48:51 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 7 Apr 2018 16:48:51 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180407.165955.1814164569110811454.levitte@openssl.org>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407.165955.1814164569110811454.levitte@openssl.org>
Message-ID: <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>

>    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
	- We are not required to do FIPS level DRBG/CSPRNG this release
	- It is probably not appropriate in an API/ABI compatible release
	- It is not appropriate for a "silent change"



From levitte at openssl.org  Sat Apr  7 16:49:50 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 07 Apr 2018 18:49:50 +0200 (CEST)
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180407154649.GA12191@roeckx.be>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407154649.GA12191@roeckx.be>
Message-ID: <20180407.184950.1252558465192115715.levitte@openssl.org>

In message <20180407154649.GA12191 at roeckx.be> on Sat, 7 Apr 2018 17:46:50 +0200, Kurt Roeckx <kurt at roeckx.be> said:

kurt> On Sat, Apr 07, 2018 at 02:15:51PM +0000, Salz, Rich wrote:
kurt> > I would like to see this put on hold until we fix the ?now requires 50% more random seeding? issue.
kurt> > 
kurt> > What should I do to force that issue?
kurt> 
kurt> NIST SP800-90A rev1 section 8.6.7 has:
kurt> | A nonce may be required in the construction of a seed during
kurt> | instantiation in order to provide a security cushion to block
kurt> | certain attacks. The nonce shall be either:
kurt> |
kurt> | a. A value with at least (security_strength/2) bits of entropy, or
kurt> | b. A value that is expected to repeat no more often than a
kurt> | (security_strength/2)-bit random string would be expected to repeat.
kurt> |
kurt> | Each nonce shall be unique to the cryptographic module in which
kurt> | instantiation is performed, but need not be secret. When used, the
kurt> | nonce shall be considered to be a critical security parameter.
kurt> |
kurt> | A nonce may be composed of one (or more) of the following
kurt> | components (other components may also be appropriate):
kurt> | 1. A random value that is generated anew for each nonce, using an
kurt> | approved random bit generator.
kurt> | 2. A timestamp of sufficient resolution (detail) so that it is
kurt> | different each time it is used.
kurt> | 3. A monotonically increasing sequence number, or
kurt> | 4. A combination of a timestamp and a monotonically increasing
kurt> | sequence number, such that the sequence number is reset when and
kurt> | only when the timestamp changes. For example, a timestamp may show
kurt> | the date but not the time of day, so a sequence number is appended
kurt> | that will not repeat during a particular day.
kurt> |
kurt> | For case 1 above, the random value could be acquired from the same
kurt> | source and at the same time as the entropy input. In this case,
kurt> | the seed could be considered to be constructed from an
kurt> | ?extra strong? entropy input and the optional personalization
kurt> | string, where the entropy for the entropy input is equal to or
kurt> | greater than (3/2 security_strength) bits.
kurt> |
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"...

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.

Hmmmm...  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?

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?

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Sat Apr  7 17:00:21 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 07 Apr 2018 19:00:21 +0200 (CEST)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180407160031.GB12191@roeckx.be>
References: <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>
 <20180407.165806.463561558996899206.levitte@openssl.org>
 <20180407160031.GB12191@roeckx.be>
Message-ID: <20180407.190021.1440492505897186731.levitte@openssl.org>

In message <20180407160031.GB12191 at roeckx.be> on Sat, 7 Apr 2018 18:00:32 +0200, Kurt Roeckx <kurt at 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.

Errrrrrr....  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.

If you wanna know what I'm talking about, just have a look at this
page:

http://h41379.www4.hpe.com/doc/84final/4527/4527pro_contents.html

Every "command" that starts with a '$' is a system service.  The C API
has them prefixed with 'sys$'.  The one of hightes interest seems to
be $GETRMI (or sys$getrmi), which has all sorts of counters and other
data.

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...

kurt> I'm going to guess that the 4 bit you count now is an overestimate.

Don't look at me, it was I who made that estimate...  but I agree with
your guess.

kurt> And I would like to be very conservative in estimating something
kurt> like that, and even divide what the tool returns by 10.

That's a reason I want to go for a computed estimate instead...  the
3rd order delta that Linux' random driver does with jiffies seemed
like a simple enough strategy.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Sat Apr  7 17:07:02 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 7 Apr 2018 17:07:02 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180407154649.GA12191@roeckx.be>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407154649.GA12191@roeckx.be>
Message-ID: <5F911EBC-C537-4E7E-9AF7-8442CE33A10E@akamai.com>


    
>    NIST SP800-90A rev1 section 8.6.7 has:

Compliance with this was never a stated goal of this release.  So not relevant.


From kurt at roeckx.be  Sat Apr  7 17:33:25 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 7 Apr 2018 19:33:25 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407.165955.1814164569110811454.levitte@openssl.org>
 <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>
Message-ID: <20180407173325.GA20279@roeckx.be>

On Sat, Apr 07, 2018 at 04:48:51PM +0000, 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


From kurt at roeckx.be  Sat Apr  7 17:43:32 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 7 Apr 2018 19:43:32 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180407.184950.1252558465192115715.levitte@openssl.org>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407154649.GA12191@roeckx.be>
 <20180407.184950.1252558465192115715.levitte@openssl.org>
Message-ID: <20180407174331.GB20279@roeckx.be>

On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> In message <20180407154649.GA12191 at roeckx.be> on Sat, 7 Apr 2018 17:46:50 +0200, Kurt Roeckx <kurt at 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.
> 
> Hmmmm...  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


From kurt at roeckx.be  Sat Apr  7 17:45:28 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 7 Apr 2018 19:45:28 +0200
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180407.190021.1440492505897186731.levitte@openssl.org>
References: <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>
 <20180407.165806.463561558996899206.levitte@openssl.org>
 <20180407160031.GB12191@roeckx.be>
 <20180407.190021.1440492505897186731.levitte@openssl.org>
Message-ID: <20180407174527.GC20279@roeckx.be>

On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote:
> In message <20180407160031.GB12191 at roeckx.be> on Sat, 7 Apr 2018 18:00:32 +0200, Kurt Roeckx <kurt at 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.
> 
> Errrrrrr....  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


From kurt at roeckx.be  Sat Apr  7 17:47:27 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 7 Apr 2018 19:47:27 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <5F911EBC-C537-4E7E-9AF7-8442CE33A10E@akamai.com>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407154649.GA12191@roeckx.be>
 <5F911EBC-C537-4E7E-9AF7-8442CE33A10E@akamai.com>
Message-ID: <20180407174727.GD20279@roeckx.be>

On Sat, Apr 07, 2018 at 05:07:02PM +0000, Salz, Rich wrote:
> 
>     
> >    NIST SP800-90A rev1 section 8.6.7 has:
> 
> Compliance with this was never a stated goal of this release.  So not relevant.

Compliance with AES was also never a stated goal.


Kurt


From rsalz at akamai.com  Sat Apr  7 17:50:33 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 7 Apr 2018 17:50:33 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180407174727.GD20279@roeckx.be>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407154649.GA12191@roeckx.be>
 <5F911EBC-C537-4E7E-9AF7-8442CE33A10E@akamai.com>
 <20180407174727.GD20279@roeckx.be>
Message-ID: <913AD604-6DD7-4442-BBDE-C6E54C7CBCCA@akamai.com>


>    Compliance with AES was also never a stated goal.
  
Implicitly it was because (a) it's a standard algorithm and (b) MTI for TLS.  But more importantly, *it didn't break anything.*



From rsalz at akamai.com  Sat Apr  7 17:55:14 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 7 Apr 2018 17:55:14 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180407173325.GA20279@roeckx.be>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407.165955.1814164569110811454.levitte@openssl.org>
 <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>
 <20180407173325.GA20279@roeckx.be>
Message-ID: <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>

    > 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 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.
   
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.

> 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.
 
    > 	- 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.

>    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?  All the more reason to revert it.

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


From levitte at openssl.org  Sat Apr  7 17:57:32 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 07 Apr 2018 19:57:32 +0200 (CEST)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180407174527.GC20279@roeckx.be>
References: <20180407160031.GB12191@roeckx.be>
 <20180407.190021.1440492505897186731.levitte@openssl.org>
 <20180407174527.GC20279@roeckx.be>
Message-ID: <20180407.195732.2304085922128075011.levitte@openssl.org>

In message <20180407174527.GC20279 at roeckx.be> on Sat, 7 Apr 2018 19:45:28 +0200, Kurt Roeckx <kurt at roeckx.be> said:

kurt> On Sat, Apr 07, 2018 at 07:00:21PM +0200, Richard Levitte wrote:
kurt> > In message <20180407160031.GB12191 at roeckx.be> on Sat, 7 Apr 2018 18:00:32 +0200, Kurt Roeckx <kurt at roeckx.be> said:
kurt> > 
kurt> > kurt> If you have such a program that collects the bits, I would like
kurt> > kurt> to review it. I would also like to test something like that over
kurt> > kurt> a range of machines it's expected to run on.
kurt> > 
kurt> > Errrrrrr....  I have no idea what you're talking about.  I know of no
kurt> > other operating system that provides the system services VMS does, so
kurt> > I wonder how you expect to run the program gathering those data on
kurt> > anything other than VMS.
kurt> 
kurt> I mean multiple VMS machines on different processors / hardware.

VMS exists for Alpha and Itanium for the moment.  VSI is working on a
x86_64 port, with the first early adopters kit available late this
year (see http://www.vmssoftware.com/pdfs/VSI_Roadmap_20171215.pdf)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kurt at roeckx.be  Sat Apr  7 18:50:35 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 7 Apr 2018 20:50:35 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407.165955.1814164569110811454.levitte@openssl.org>
 <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>
 <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
Message-ID: <20180407185034.GA25532@roeckx.be>

On Sat, Apr 07, 2018 at 05:55:14PM +0000, 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


From kurt at roeckx.be  Sat Apr  7 19:02:51 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 7 Apr 2018 21:02:51 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180407.184950.1252558465192115715.levitte@openssl.org>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407154649.GA12191@roeckx.be>
 <20180407.184950.1252558465192115715.levitte@openssl.org>
Message-ID: <20180407190250.GA27401@roeckx.be>

On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> Hmmmm...  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?

The requirement is not to have it 128 bit. Just that it doesn't
repeat as often as a 128 random number. You're most likely not
going to instantiate it 2^64 times. As long as the combination is
unique, it should be fine.

(It does say that it needs to be at least 128 bit, but I think
that's actually only in the case that you use a random number.)


Kurt


From levitte at openssl.org  Sun Apr  8 05:15:32 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 08 Apr 2018 07:15:32 +0200 (CEST)
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180407185034.GA25532@roeckx.be>
References: <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
 <20180407185034.GA25532@roeckx.be>
Message-ID: <20180408.071532.1946486666584070263.levitte@openssl.org>

In message <20180407185034.GA25532 at roeckx.be> on Sat, 7 Apr 2018 20:50:35 +0200, Kurt Roeckx <kurt at roeckx.be> said:

kurt> > In going from 1.1.0 to 1.1.1, breaking platforms that used to
kurt> > work is just plain wrong.
kurt> 
kurt> So then I suggest we support the syscalls on all platforms that
kurt> provide it.

I'm sorry, I'm lost.  "the syscalls"?  You started refering to
syscalls when discussing getrandom(), so I'm going to assume that it's
related, but I fail to understand how it's related to platforms that
break, and most specifically to VMS.  What "syscalls" do you expect?

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Sun Apr  8 05:39:30 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 08 Apr 2018 07:39:30 +0200 (CEST)
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180407190250.GA27401@roeckx.be>
References: <20180407154649.GA12191@roeckx.be>
 <20180407.184950.1252558465192115715.levitte@openssl.org>
 <20180407190250.GA27401@roeckx.be>
Message-ID: <20180408.073930.1951958871788306755.levitte@openssl.org>

In message <20180407190250.GA27401 at roeckx.be> on Sat, 7 Apr 2018 21:02:51 +0200, Kurt Roeckx <kurt at roeckx.be> said:

kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
kurt> > Hmmmm...  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.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kurt at roeckx.be  Sun Apr  8 07:49:58 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 8 Apr 2018 09:49:58 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180408.071532.1946486666584070263.levitte@openssl.org>
References: <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
 <20180407185034.GA25532@roeckx.be>
 <20180408.071532.1946486666584070263.levitte@openssl.org>
Message-ID: <20180408074958.GA3653@roeckx.be>

On Sun, Apr 08, 2018 at 07:15:32AM +0200, Richard Levitte wrote:
> In message <20180407185034.GA25532 at roeckx.be> on Sat, 7 Apr 2018 20:50:35 +0200, Kurt Roeckx <kurt at roeckx.be> said:
> 
> kurt> > In going from 1.1.0 to 1.1.1, breaking platforms that used to
> kurt> > work is just plain wrong.
> kurt> 
> kurt> So then I suggest we support the syscalls on all platforms that
> kurt> provide it.
> 
> I'm sorry, I'm lost.  "the syscalls"?  You started refering to
> syscalls when discussing getrandom(), so I'm going to assume that it's
> related, but I fail to understand how it's related to platforms that
> break, and most specifically to VMS.  What "syscalls" do you expect?

This is not related to VMS. What I see as most likely to break
going from 1.1.0 to 1.1.1 is reseeding in a chroot. This can be
solved by using a system call instead of /dev/urandom if it's
available.


Kurt


From kurt at roeckx.be  Sun Apr  8 08:09:42 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 8 Apr 2018 10:09:42 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180408.073930.1951958871788306755.levitte@openssl.org>
References: <20180407154649.GA12191@roeckx.be>
 <20180407.184950.1252558465192115715.levitte@openssl.org>
 <20180407190250.GA27401@roeckx.be>
 <20180408.073930.1951958871788306755.levitte@openssl.org>
Message-ID: <20180408080942.GB3653@roeckx.be>

On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote:
> In message <20180407190250.GA27401 at roeckx.be> on Sat, 7 Apr 2018 21:02:51 +0200, Kurt Roeckx <kurt at roeckx.be> said:
> 
> kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> kurt> > Hmmmm...  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


From bernd.edlinger at hotmail.de  Sun Apr  8 08:19:09 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Sun, 8 Apr 2018 08:19:09 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180408074958.GA3653@roeckx.be>
References: <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
 <20180407185034.GA25532@roeckx.be>
 <20180408.071532.1946486666584070263.levitte@openssl.org>
 <20180408074958.GA3653@roeckx.be>
Message-ID: <AM5PR0701MB2657637715F34B438096828CE4B80@AM5PR0701MB2657.eurprd07.prod.outlook.com>

On 04/08/18 09:49, Kurt Roeckx wrote:
> On Sun, Apr 08, 2018 at 07:15:32AM +0200, Richard Levitte wrote:
>> In message <20180407185034.GA25532 at roeckx.be> on Sat, 7 Apr 2018 20:50:35 +0200, Kurt Roeckx <kurt at roeckx.be> said:
>>
>> kurt> > In going from 1.1.0 to 1.1.1, breaking platforms that used to
>> kurt> > work is just plain wrong.
>> kurt>
>> kurt> So then I suggest we support the syscalls on all platforms that
>> kurt> provide it.
>>
>> I'm sorry, I'm lost.  "the syscalls"?  You started refering to
>> syscalls when discussing getrandom(), so I'm going to assume that it's
>> related, but I fail to understand how it's related to platforms that
>> break, and most specifically to VMS.  What "syscalls" do you expect?
> 
> This is not related to VMS. What I see as most likely to break
> going from 1.1.0 to 1.1.1 is reseeding in a chroot. This can be
> solved by using a system call instead of /dev/urandom if it's
> available.
> 
> 

You say /dev/urandom is accessible on startup but no longer after
the process calls chroot?

If that is the problem, maybe the device could be opened on startup
and just left open for later reseeding?


Bernd.

From levitte at openssl.org  Sun Apr  8 08:31:58 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 08 Apr 2018 10:31:58 +0200 (CEST)
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180408080942.GB3653@roeckx.be>
References: <20180407190250.GA27401@roeckx.be>
 <20180408.073930.1951958871788306755.levitte@openssl.org>
 <20180408080942.GB3653@roeckx.be>
Message-ID: <20180408.103158.5427624525303816.levitte@openssl.org>

In message <20180408080942.GB3653 at roeckx.be> on Sun, 8 Apr 2018 10:09:42 +0200, Kurt Roeckx <kurt at roeckx.be> said:

kurt> On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote:
kurt> > In message <20180407190250.GA27401 at roeckx.be> on Sat, 7 Apr 2018 21:02:51 +0200, Kurt Roeckx <kurt at roeckx.be> said:
kurt> > 
kurt> > kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
kurt> > kurt> > Hmmmm...  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.

I don't know enough to decide what's appropriate here...

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kurt at roeckx.be  Sun Apr  8 09:10:06 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 8 Apr 2018 11:10:06 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180408.103158.5427624525303816.levitte@openssl.org>
References: <20180407190250.GA27401@roeckx.be>
 <20180408.073930.1951958871788306755.levitte@openssl.org>
 <20180408080942.GB3653@roeckx.be>
 <20180408.103158.5427624525303816.levitte@openssl.org>
Message-ID: <20180408091006.GA6923@roeckx.be>

On Sun, Apr 08, 2018 at 10:31:58AM +0200, Richard Levitte wrote:
> In message <20180408080942.GB3653 at roeckx.be> on Sun, 8 Apr 2018 10:09:42 +0200, Kurt Roeckx <kurt at roeckx.be> said:
> 
> kurt> On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote:
> kurt> > In message <20180407190250.GA27401 at roeckx.be> on Sat, 7 Apr 2018 21:02:51 +0200, Kurt Roeckx <kurt at roeckx.be> said:
> kurt> > 
> kurt> > kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> kurt> > kurt> > Hmmmm...  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


From rsalz at akamai.com  Sun Apr  8 12:21:10 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 8 Apr 2018 12:21:10 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180408.071532.1946486666584070263.levitte@openssl.org>
References: <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
 <20180407185034.GA25532@roeckx.be>
 <20180408.071532.1946486666584070263.levitte@openssl.org>
Message-ID: <B7085D9C-C0DC-4280-85F3-047DBA90B81D@akamai.com>

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

Who takes responsibility for fixing this?



From rsalz at akamai.com  Sun Apr  8 12:24:08 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 8 Apr 2018 12:24:08 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180408091006.GA6923@roeckx.be>
References: <20180407190250.GA27401@roeckx.be>
 <20180408.073930.1951958871788306755.levitte@openssl.org>
 <20180408080942.GB3653@roeckx.be>
 <20180408.103158.5427624525303816.levitte@openssl.org>
 <20180408091006.GA6923@roeckx.be>
Message-ID: <A6BFC307-4238-4B37-868D-47D845C2FB87@akamai.com>

>    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 bits.  I deliberately stayed away from all RAND stuff after the initial PR, because I didn't want to step on anyone else's toes and "hog" the work.  I knew others (including Kurt) were very interested in this.

Who is going to ensure that we improve the code?



From levitte at openssl.org  Sun Apr  8 13:21:16 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 08 Apr 2018 15:21:16 +0200 (CEST)
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <A6BFC307-4238-4B37-868D-47D845C2FB87@akamai.com>
References: <20180408.103158.5427624525303816.levitte@openssl.org>
 <20180408091006.GA6923@roeckx.be>
 <A6BFC307-4238-4B37-868D-47D845C2FB87@akamai.com>
Message-ID: <20180408.152116.1685472938257409014.levitte@openssl.org>

In message <A6BFC307-4238-4B37-868D-47D845C2FB87 at akamai.com> on Sun, 8 Apr 2018 12:24:08 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> >    Yes, after what I all said previously, it's clear the code could
rsalz>     use improvements. I think at least Matthias and I assumed the code
rsalz>     about the minimum size was correct and that there was a minimum
rsalz>     requirement of 128 bit.
rsalz>   
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?

rsalz> I deliberately stayed away from all RAND stuff after the
rsalz> initial PR, because I didn't want to step on anyone else's toes
rsalz> and "hog" the work.  I knew others (including Kurt) were very
rsalz> interested in this.
rsalz> Who is going to ensure that we improve the code?

All things considered, I think "we" will.  There seems to be enough
discussion going on among interested parties, and it does sound like
we want to find a common ground.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Sun Apr  8 14:10:36 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 8 Apr 2018 14:10:36 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180408.152116.1685472938257409014.levitte@openssl.org>
References: <20180408.103158.5427624525303816.levitte@openssl.org>
 <20180408091006.GA6923@roeckx.be>
 <A6BFC307-4238-4B37-868D-47D845C2FB87@akamai.com>
 <20180408.152116.1685472938257409014.levitte@openssl.org>
Message-ID: <66DB0D80-1995-4C33-B61C-C1F01DE6EAD1@akamai.com>

    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 requirement would only be 128 bits.  As to what happens if more is available, that's not relevant to what I was trying to say.




From kurt at roeckx.be  Sun Apr  8 15:36:27 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 8 Apr 2018 17:36:27 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180407185034.GA25532@roeckx.be>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407.165955.1814164569110811454.levitte@openssl.org>
 <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>
 <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
 <20180407185034.GA25532@roeckx.be>
Message-ID: <20180408153627.GA16453@roeckx.be>

On Sat, Apr 07, 2018 at 08:50:35PM +0200, Kurt Roeckx wrote:
> On Sat, Apr 07, 2018 at 05:55:14PM +0000, 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


From levitte at openssl.org  Sun Apr  8 17:15:16 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 08 Apr 2018 19:15:16 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
	demand for this platform specifically (#5904)
In-Reply-To: <20180408153627.GA16453@roeckx.be>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407.165955.1814164569110811454.levitte@openssl.org>
 <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>
 <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
 <20180407185034.GA25532@roeckx.be> <20180408153627.GA16453@roeckx.be>
Message-ID: <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>



Kurt Roeckx <kurt at 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 +0000, 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? 

>
>
>Kurt
>
>_______________________________________________
>openssl-project mailing list
>openssl-project at openssl.org
>https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From kurt at roeckx.be  Sun Apr  8 19:37:37 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 8 Apr 2018 21:37:37 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407.165955.1814164569110811454.levitte@openssl.org>
 <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>
 <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
 <20180407185034.GA25532@roeckx.be>
 <20180408153627.GA16453@roeckx.be>
 <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>
Message-ID: <20180408193737.GA6310@roeckx.be>

On Sun, Apr 08, 2018 at 07:15:16PM +0200, Richard Levitte wrote:
> 
> 
> Kurt Roeckx <kurt at 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 +0000, 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


From Matthias.St.Pierre at ncp-e.com  Sun Apr  8 19:52:53 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Sun, 8 Apr 2018 19:52:53 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180408193737.GA6310@roeckx.be>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407.165955.1814164569110811454.levitte@openssl.org>
 <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>
 <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
 <20180407185034.GA25532@roeckx.be> <20180408153627.GA16453@roeckx.be>
 <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>
 <20180408193737.GA6310@roeckx.be>
Message-ID: <c70dd9086f684147865472f2db70e446@Ex13.ncp.local>

> > 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


Even if your claim about the 768 bits of entropy is correct, it only proves that it was a good idea to make the derivation function the default in commit 8164d91d1802e6173291dee50923cc60fcd3bf72.

Matthias


https://github.com/openssl/openssl/commit/8164d91d1802e6173291dee50923cc60fcd3bf72

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180408/3cc1e5ba/attachment-0001.bin>

From rsalz at akamai.com  Sun Apr  8 20:10:22 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 8 Apr 2018 20:10:22 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180408193737.GA6310@roeckx.be>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407.165955.1814164569110811454.levitte@openssl.org>
 <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>
 <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
 <20180407185034.GA25532@roeckx.be> <20180408153627.GA16453@roeckx.be>
 <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>
 <20180408193737.GA6310@roeckx.be>
Message-ID: <A8D5BBDD-2662-44A1-BA9C-C8C52F30491E@akamai.com>

>    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.


From Matthias.St.Pierre at ncp-e.com  Sun Apr  8 20:29:18 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Sun, 8 Apr 2018 20:29:18 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <A8D5BBDD-2662-44A1-BA9C-C8C52F30491E@akamai.com>
References: <openssl/openssl/pull/5904@github.com>
 <116A311C-48B3-4181-9E68-B2FCC8D2D06E@akamai.com>
 <20180407.165955.1814164569110811454.levitte@openssl.org>
 <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>
 <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
 <20180407185034.GA25532@roeckx.be> <20180408153627.GA16453@roeckx.be>
 <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>
 <20180408193737.GA6310@roeckx.be>
 <A8D5BBDD-2662-44A1-BA9C-C8C52F30491E@akamai.com>
Message-ID: <fea9453447a047cdb49e4380fa9988f2@Ex13.ncp.local>

Just for completeness sake: The entropy requirement is 256 and *not* 384 if a derivation function is used.

Please reread https://mta.openssl.org/pipermail/openssl-project/2018-April/000506.html

> -----Urspr?ngliche Nachricht-----
> Von: openssl-project <openssl-project-bounces at openssl.org> Im Auftrag von Salz, Rich
> Gesendet: Sonntag, 8. April 2018 22:10
> An: openssl-project at openssl.org
> Betreff: Re: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)
> 
> >    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 at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180408/85d5d627/attachment.bin>

From levitte at openssl.org  Sun Apr  8 21:30:56 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 08 Apr 2018 23:30:56 +0200 (CEST)
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>
References: <20180407185034.GA25532@roeckx.be>
 <20180408153627.GA16453@roeckx.be>
 <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>
Message-ID: <20180408.233056.1365006098046277169.levitte@openssl.org>

In message <83AE9015-A766-4497-A71D-D537837CF04A at openssl.org> on Sun, 08 Apr 2018 19:15:16 +0200, Richard Levitte <levitte at openssl.org> said:

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

Ah, hold on, that was without a DF, but we *are* using a DF by
default, which makes sense since we can't possibly assume that we have
an approved RBG or an entropy source that provides "full entropy",
hence, according to 10.2.1 in SP800-90Ar1:

| The use of the derivation function is optional if either an
| *approved* RBG or an entropy source provides full entropy output
| when entropy input is requested by the DRBG mechanism. Otherwise,
| the derivation function *shall* be used.

This also puts into question the no_df tests in test/drbgtest.c, how
can we possibly, under the diverse conditions we're facing, assume to
know if those tests will succeed or fail?

So I guess I'm still on track with wanting to specify a get_nonce
function for VMS.  Speaking of that, got any ideas on how to hook that
on appropriately, without butchering the current DRBG code?

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Sun Apr  8 21:32:27 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 08 Apr 2018 23:32:27 +0200 (CEST)
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <A8D5BBDD-2662-44A1-BA9C-C8C52F30491E@akamai.com>
References: <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>
 <20180408193737.GA6310@roeckx.be>
 <A8D5BBDD-2662-44A1-BA9C-C8C52F30491E@akamai.com>
Message-ID: <20180408.233227.330556361436661579.levitte@openssl.org>

In message <A8D5BBDD-2662-44A1-BA9C-C8C52F30491E at akamai.com> on Sun, 8 Apr 2018 20:10:22 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> >    The 384 comes straight out of SP800-90A, see the table 10.2.1.
rsalz>   
rsalz> I think we're getting close to needing a team vote on whether
rsalz> or not we want to follow SP800-90A for this release.

Hold that thought a moment more...

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/


From kurt at roeckx.be  Sun Apr  8 21:33:25 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 8 Apr 2018 23:33:25 +0200
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <fea9453447a047cdb49e4380fa9988f2@Ex13.ncp.local>
References: <20180407.165955.1814164569110811454.levitte@openssl.org>
 <E5AD58BB-E4FA-4AFB-82F2-791DC779D47D@akamai.com>
 <20180407173325.GA20279@roeckx.be>
 <EF80C30D-7FD6-4721-9383-2B6E58F3FD1F@akamai.com>
 <20180407185034.GA25532@roeckx.be>
 <20180408153627.GA16453@roeckx.be>
 <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>
 <20180408193737.GA6310@roeckx.be>
 <A8D5BBDD-2662-44A1-BA9C-C8C52F30491E@akamai.com>
 <fea9453447a047cdb49e4380fa9988f2@Ex13.ncp.local>
Message-ID: <20180408213325.GA11894@roeckx.be>

On Sun, Apr 08, 2018 at 08:29:18PM +0000, 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


From Matthias.St.Pierre at ncp-e.com  Sun Apr  8 21:51:52 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Sun, 8 Apr 2018 21:51:52 +0000
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <20180408.233056.1365006098046277169.levitte@openssl.org>
References: <20180407185034.GA25532@roeckx.be>
 <20180408153627.GA16453@roeckx.be>
 <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>
 <20180408.233056.1365006098046277169.levitte@openssl.org>
Message-ID: <be412f7fcc0040dca1d205c3eb452878@Ex13.ncp.local>

> This also puts into question the no_df tests in test/drbgtest.c, how
> can we possibly, under the diverse conditions we're facing, assume to
> know if those tests will succeed or fail?

The no_df tests are o.k. as they are. In fact, OpenSSL supports using the DRBG with or without the derivation function. We ourselves, we are not using the no_df feature. But that does not mean we have to rip it out of our sources. It's there since FIPS 2.0 and it's implemented correctly. A possible use case would be the following: if an application has access to a true RNG then it could replace the get_entropy() callbacks and operate our DRBG without the derivation function. 



> So I guess I'm still on track with wanting to specify a get_nonce
> function for VMS.  Speaking of that, got any ideas on how to hook that
> on appropriately, without butchering the current DRBG code?

Hold the line, I'm currently working on it...  

Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180408/8f9b7fb9/attachment-0001.bin>

From levitte at openssl.org  Sun Apr  8 21:55:16 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 08 Apr 2018 23:55:16 +0200 (CEST)
Subject: [openssl-project] FW: [openssl/openssl] VMS: lower the entropy
 demand for this platform specifically (#5904)
In-Reply-To: <be412f7fcc0040dca1d205c3eb452878@Ex13.ncp.local>
References: <83AE9015-A766-4497-A71D-D537837CF04A@openssl.org>
 <20180408.233056.1365006098046277169.levitte@openssl.org>
 <be412f7fcc0040dca1d205c3eb452878@Ex13.ncp.local>
Message-ID: <20180408.235516.1999820736189586116.levitte@openssl.org>

In message <be412f7fcc0040dca1d205c3eb452878 at Ex13.ncp.local> on Sun, 8 Apr 2018 21:51:52 +0000, "Dr. Matthias St. Pierre" <Matthias.St.Pierre at ncp-e.com> said:

Matthias.St.Pierre> > So I guess I'm still on track with wanting to specify a get_nonce
Matthias.St.Pierre> > function for VMS.  Speaking of that, got any ideas on how to hook that
Matthias.St.Pierre> > on appropriately, without butchering the current DRBG code?
Matthias.St.Pierre> 
Matthias.St.Pierre> Hold the line, I'm currently working on it...  

Cool, I'll hold.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kurt at roeckx.be  Mon Apr  9 17:12:41 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 9 Apr 2018 19:12:41 +0200
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180407.190021.1440492505897186731.levitte@openssl.org>
References: <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>
 <20180407.165806.463561558996899206.levitte@openssl.org>
 <20180407160031.GB12191@roeckx.be>
 <20180407.190021.1440492505897186731.levitte@openssl.org>
Message-ID: <20180409171241.GA24226@roeckx.be>

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


From appro at openssl.org  Mon Apr  9 18:55:10 2018
From: appro at openssl.org (Andy Polyakov)
Date: Mon, 9 Apr 2018 20:55:10 +0200
Subject: [openssl-project] SM2
Message-ID: <5f213ce8-6eee-abc6-c8ac-a4768e8a4c6c@openssl.org>

Hi,

I'd like to hear *more* opinions in light of recent comments to
https://github.com/openssl/openssl/pull/4793. (Strangely enough I get
"This page is taking way too long to load" if attempt to access it when
I'm logged on[!?]. But I have no problems opening requests from the
middle, long closed.) As for my opinion I found myself objecting the way
SM2 is hammered into ec_pmeth.c, and it's irregardless concerns risen in
4793, which merely enforced the opinion. Concern is that we risk being
stuck with maintaining quirky behaviour for long time. It should really
be up to application to choose the scheme (as suggested in 4793) or SM2
methods should be parameterizeable. This means that I'd like to raise a
voice in favour of removal the hacks. If it means missing release, I'd
argue that it's better to miss it than to get stuck with something that
would be problematic to support.

From rsalz at dev.openssl.org  Tue Apr 10 02:00:12 2018
From: rsalz at dev.openssl.org (Rich Salz)
Date: Mon, 9 Apr 2018 22:00:12 -0400
Subject: [openssl-project] OpenSSL FIPS Validation 1747 is not being labeled
	historic
Message-ID: <20180410020012.GA17194@dev.openssl.org>

We have been getting asked about the status of the OpenSSL FIPS 2.0
Validation, Certificate 1747 [1]. In particular, they read the notice
about "symmetric key wrapping"[2] and wondered if OpenSSL would
be moved to the Historical list.

The OpenSSL validation testing was performed by InfoGard Laboratories,
which is now known as UL Verification Services[3]. The program manager
was Marc Ireland. Marc has the same role at UL.  In response to our
question about this, he said the following:
	The transition for that was January 1st, so it would have already
	been moved.  We submitted updated Security Policies late last
	year to avoid it being moved.

We hope this alleviates everyone's concern. We thank Mark Minnoch of
KeyPair Consulting who had earlier posted the same thing[4].

[1] https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/1747
[2] https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Notices
[3] https://www.ul-ts.com/standards/fips/c-38/c-1863
[4] https://mta.openssl.org/pipermail/openssl-users/2018-March/007668.html

From rsalz at akamai.com  Tue Apr 10 02:03:54 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 10 Apr 2018 02:03:54 +0000
Subject: [openssl-project] VOTE on coding style changes
Message-ID: <4B10AFF4-57E2-4489-82B7-F693669D0218@akamai.com>

This is an old message that had been held up in the moderator queue.  Ignore it.

From: Rich Salz <rsalz at akamai.com>
Reply-To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Date: Monday, April 9, 2018 at 10:02 PM
To: "openssl-omc at openssl.org" <openssl-omc at openssl.org>
Subject: [openssl-project] VOTE on coding style changes

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 the text of https://github.com/openssl/web/pull/43
into the coding style policy.
Proposed by Rich
Public: yes
opened: 2016-03-26
closed: yyyy-mm-dd

  Matt       [  ]
  Mark       [  ]
  Viktor     [  ]
  Tim        [  ]
  Emilia     [  ]
  Richard    [  ]
  Kurt       [  ]
  Rich       [+1]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180410/9b84a2d0/attachment.html>

From rsalz at akamai.com  Tue Apr 10 02:07:37 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 10 Apr 2018 02:07:37 +0000
Subject: [openssl-project] Vote results -- coding style
Message-ID: <A8111304-D13C-4FC6-B36C-FB4E1E847924@akamai.com>

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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180410/b1679a7b/attachment.html>

From rsalz at akamai.com  Wed Apr 11 19:31:57 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Apr 2018 19:31:57 +0000
Subject: [openssl-project] FIPS support and sponsorship
In-Reply-To: <CAOuge22nKUWiy_LQ-+4yku2jhCeo2fA7z5Ua0G8pVkka=CWToA@mail.gmail.com>
References: <CAOuge22nKUWiy_LQ-+4yku2jhCeo2fA7z5Ua0G8pVkka=CWToA@mail.gmail.com>
Message-ID: <5C242244-B9E0-4292-AAD5-E3B67E9493C2@akamai.com>

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 <pdm at box.com>
Reply-To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Date: Monday, April 9, 2018 at 10:03 PM
To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Subject: [openssl-project] FIPS support and sponsorship


Hi,

I would like to talk with some one about my company possibly sponsoring OpenSSL to get 1.1 or newer enabled with FIPS support. I know there have been some other sponsorships and setbacks from sponsors leaving. I'd like to understand the roadmap for FIPS and what support you need to be able to see a newer version of OpenSSL with FIPS support.

Thanks,
Phillip Moore

--
Phillip Moore
Staff Site Reliability Engineer / Box
pdm at box.com<mailto:pdm at box.com> / 571-213-4323
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180411/e8b53f4c/attachment-0001.html>

From rsalz at akamai.com  Wed Apr 11 19:32:46 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Apr 2018 19:32:46 +0000
Subject: [openssl-project] FIPS support and sponsorship
In-Reply-To: <5C242244-B9E0-4292-AAD5-E3B67E9493C2@akamai.com>
References: <CAOuge22nKUWiy_LQ-+4yku2jhCeo2fA7z5Ua0G8pVkka=CWToA@mail.gmail.com>
 <5C242244-B9E0-4292-AAD5-E3B67E9493C2@akamai.com>
Message-ID: <5FDE715E-74BF-4360-A03D-C8B0A5A9D3C9@akamai.com>


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 <pdm at box.com>
Reply-To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Date: Monday, April 9, 2018 at 10:03 PM
To: "openssl-project at openssl.org" <openssl-project at openssl.org>
Subject: [openssl-project] FIPS support and sponsorship


Hi,

I would like to talk with some one about my company possibly sponsoring OpenSSL to get 1.1 or newer enabled with FIPS support. I know there have been some other sponsorships and setbacks from sponsors leaving. I'd like to understand the roadmap for FIPS and what support you need to be able to see a newer version of OpenSSL with FIPS support.

Thanks,
Phillip Moore

--
Phillip Moore
Staff Site Reliability Engineer / Box
pdm at box.com<mailto:pdm at box.com> / 571-213-4323
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180411/98149b6f/attachment.html>

From rsalz at akamai.com  Thu Apr 12 01:42:46 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 12 Apr 2018 01:42:46 +0000
Subject: [openssl-project] Some TLS 1.3 drafts don't have branches
Message-ID: <6796422D-5B06-4597-B2EE-4B7C6ED2032E@akamai.com>

; 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 branches for the drafts we released?  And I guess ?we? means ?you, please, Matt?

                /r$

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180412/8e447037/attachment.html>

From matt at openssl.org  Thu Apr 12 09:51:49 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 12 Apr 2018 10:51:49 +0100
Subject: [openssl-project] Some TLS 1.3 drafts don't have branches
In-Reply-To: <6796422D-5B06-4597-B2EE-4B7C6ED2032E@akamai.com>
References: <6796422D-5B06-4597-B2EE-4B7C6ED2032E@akamai.com>
Message-ID: <bf2731f6-5d3d-3d63-205b-89fc40fc8ee2@openssl.org>



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
> 
> ? remotes/origin/tls1.3-draft-19? ???????????d4d9864 Update PR#3925
> 
> ;
> 
> ?
> 
> I recently had someone need draft-21 and they did
> 
> ?
> 
> git checkout 515982154031b679f58d5e2cbd7752294779221e

That's the last commit of the PR that introduced draft-21 support. A
better commit would be f90852093f which is the last commit before
draft-22 support was added.

I think tags are more appropriate than branches. We created a branch for
draft-18 because at the time all the browsers were stuck on that draft
version with no sign that they might move for a while so we thought we
might end up backporting fixes to the draft-18 branch (which I think we
did do in a few cases). Now though I think it's unlikely we would
backport fixes to older draft releases.

I'd suggest these tags for the various draft versions:

tls1.3-draft-20 9561e2a169
tls1.3-draft-21 f90852093f
tls1.3-draft-22 eee8a40aa5
tls1.3-draft-23 95ea8da176

The current version number declared in supported_versions at the head of
master is draft-26 (we skipped support for draft-24 and draft-25). This
seems to be the one everyone else is still using. The current document
is at draft-28 but there have been no incompatible changes (other than
the draft version number itself).

If someone gives me a +1 I'll create the above.

Matt


From levitte at openssl.org  Thu Apr 12 11:38:34 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 12 Apr 2018 13:38:34 +0200 (CEST)
Subject: [openssl-project] Some TLS 1.3 drafts don't have branches
In-Reply-To: <bf2731f6-5d3d-3d63-205b-89fc40fc8ee2@openssl.org>
References: <6796422D-5B06-4597-B2EE-4B7C6ED2032E@akamai.com>
 <bf2731f6-5d3d-3d63-205b-89fc40fc8ee2@openssl.org>
Message-ID: <20180412.133834.2168269306724217369.levitte@openssl.org>

In message <bf2731f6-5d3d-3d63-205b-89fc40fc8ee2 at openssl.org> on Thu, 12 Apr 2018 10:51:49 +0100, Matt Caswell <matt at openssl.org> said:

matt> I'd suggest these tags for the various draft versions:
matt> 
matt> tls1.3-draft-20 9561e2a169
matt> tls1.3-draft-21 f90852093f
matt> tls1.3-draft-22 eee8a40aa5
matt> tls1.3-draft-23 95ea8da176
matt> 
matt> The current version number declared in supported_versions at the head of
matt> master is draft-26 (we skipped support for draft-24 and draft-25). This
matt> seems to be the one everyone else is still using. The current document
matt> is at draft-28 but there have been no incompatible changes (other than
matt> the draft version number itself).
matt> 
matt> If someone gives me a +1 I'll create the above.

+1

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Thu Apr 12 12:16:16 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 12 Apr 2018 12:16:16 +0000
Subject: [openssl-project] Some TLS 1.3 drafts don't have branches
In-Reply-To: <bf2731f6-5d3d-3d63-205b-89fc40fc8ee2@openssl.org>
References: <6796422D-5B06-4597-B2EE-4B7C6ED2032E@akamai.com>
 <bf2731f6-5d3d-3d63-205b-89fc40fc8ee2@openssl.org>
Message-ID: <AACFBAE9-396E-4C81-B8EF-808131DF4669@akamai.com>

+1

?On 4/12/18, 5:51 AM, "Matt Caswell" <matt at 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
    > 
    >   remotes/origin/tls1.3-draft-19             d4d9864 Update PR#3925
    > 
    > ;
    > 
    >  
    > 
    > I recently had someone need draft-21 and they did
    > 
    >  
    > 
    > git checkout 515982154031b679f58d5e2cbd7752294779221e
    
    That's the last commit of the PR that introduced draft-21 support. A
    better commit would be f90852093f which is the last commit before
    draft-22 support was added.
    
    I think tags are more appropriate than branches. We created a branch for
    draft-18 because at the time all the browsers were stuck on that draft
    version with no sign that they might move for a while so we thought we
    might end up backporting fixes to the draft-18 branch (which I think we
    did do in a few cases). Now though I think it's unlikely we would
    backport fixes to older draft releases.
    
    I'd suggest these tags for the various draft versions:
    
    tls1.3-draft-20 9561e2a169
    tls1.3-draft-21 f90852093f
    tls1.3-draft-22 eee8a40aa5
    tls1.3-draft-23 95ea8da176
    
    The current version number declared in supported_versions at the head of
    master is draft-26 (we skipped support for draft-24 and draft-25). This
    seems to be the one everyone else is still using. The current document
    is at draft-28 but there have been no incompatible changes (other than
    the draft version number itself).
    
    If someone gives me a +1 I'll create the above.
    
    Matt
    
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project


From levitte at openssl.org  Sat Apr 14 19:32:31 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 14 Apr 2018 21:32:31 +0200 (CEST)
Subject: [openssl-project] The problem of (implicit) relinking and changed
	behaviour
Message-ID: <20180414.213231.903361400025235343.levitte@openssl.org>

Hi,

First, a note: I don't want this discussion to be just about technical
details, but also about philosophy, and guidance for policy making in
the long run.  My feeling is that we've been...  well, a bit lax with
regards to library upgrade and program relinking (explicit or
implicit, that shouldn't really matter).

Some time ago, I engaged in the exercise to see how well the test
programs from the 1.1.0 branch would do if linked with the 1.1.1
libraries (i.e. simulating a shared library upgrade from 1.1.0 to
1.1.1).  See https://github.com/openssl/openssl/issues/5661

The conclusion drawn from this exercise is that TLSv1.3 has introduced
a behaviour in libssl 1.1.1 that is incompatible with libssl 1.1.0.
Not in every function, so for example, running basic s_server or
s_client without any special options will work without issues, but
just the fact that some amount of 1.1.0 tests fail when faced with
libssl 1.1.1 tells me that there are some incompatibilities to deal
with.

Of course, one might argue that one can assume that a program that
can't deal with certain details will tell libssl to stick with TLSv1.2
or older...  but I'm unsure if such assumptions are realistic, and I'm
again looking at the 1.1.0 test failures.  Obviously, *we* didn't work
along such assumptions.

So regarding assumptions, there's only one assumption that I'm ready
to make: a program that worked correctly with libssl 1.1.0 and uses
its functionality as advertised should work the same with libssl
1.1.1.  Note that I'm not saying that this excludes new features
"under the hood", but in that case, those new features should work
transparently enough that a program doesn't need to be changed because
of them.  Also, note again that I'm not talking about recompilation,
but the implicit relinking that is what happens when a shared library
is upgraded but keeps the same library version number (no "bump").
(mind you, explicit relinking would make no different in this regard).

Does anyone disagree with that assumption?

So, how to deal with this?

1. There's the option of making the new release 1.2.0 instead of 1.1.1.
   I think most of us aren't keen on this, but it has to be said.

2. Make TLSv1.2 the absolutely maximum TLS version available for
   programs linked with libssl 1.1.0.  This is what's done in this PR:
   https://github.com/openssl/openssl/pull/5945
   This makes sense insofar that it's safe, it works within the known
   parameters for the library these programs were built for.
   It also makes sense if we view TLSv1.3 as new functionality, and
   new functionality is usually only available to those who
   explicitely build their programs for the new library version.
   TLSv1.3 is unusual in this sense because it's at least it great
   part "under the hood", just no 100% transparently so.

3. ....  I dunno, please share ideas if you have them.


Side discussion:  Some of the failing 1.1.0 tests shows that we've
made some changes in 1.1.1 that we might not have thought would
disrupt anything.

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...

b. 1.1.0's test/recipes/80-test_ssl_new.t fails in the second test
   (protocol version checks) because it expects an InternalError
   alert, but gets ClientFail instead.  So the question here is, what
   if some program actually pays attention to them?  ...  and it also
   begs the question if the alert type change was a bug fix, and in
   that case, why didn't it propagate to 1.1.0?  Should it?

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kurt at roeckx.be  Sat Apr 14 19:42:45 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 14 Apr 2018 21:42:45 +0200
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180414.213231.903361400025235343.levitte@openssl.org>
References: <20180414.213231.903361400025235343.levitte@openssl.org>
Message-ID: <20180414194244.GA27858@roeckx.be>

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


From levitte at openssl.org  Sat Apr 14 19:54:41 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 14 Apr 2018 21:54:41 +0200 (CEST)
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180414194244.GA27858@roeckx.be>
References: <20180414.213231.903361400025235343.levitte@openssl.org>
 <20180414194244.GA27858@roeckx.be>
Message-ID: <20180414.215441.596452434009486184.levitte@openssl.org>

In message <20180414194244.GA27858 at roeckx.be> on Sat, 14 Apr 2018 21:42:45 +0200, Kurt Roeckx <kurt at roeckx.be> said:

kurt> On Sat, Apr 14, 2018 at 09:32:31PM +0200, Richard Levitte wrote:
kurt> > 
kurt> > a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests
kurt> >    that are meant to fail (i.e. if the individual tests fail, the
kurt> >    recipe is successful).  When run against 1.1.1 libraries, the
kurt> >    recipe fails, i.e. the injection of double hellos didn't get the
kurt> >    communication to fail, or so it seems...
kurt> 
kurt> This seems to be a test that is very aware of the protocol, and
kurt> what should fail and what shouldn't. If you introduce a new
kurt> protocol, the things it check might need to be updated. This is
kurt> not something a normal application will be doing, so I don't see
kurt> this as a problem.

Yes, I agree that the TLSProxy tests aren't the most important in this
regard.  Also note that this part was a side note.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kurt at roeckx.be  Sat Apr 14 20:00:10 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 14 Apr 2018 22:00:10 +0200
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180414.215441.596452434009486184.levitte@openssl.org>
References: <20180414.213231.903361400025235343.levitte@openssl.org>
 <20180414194244.GA27858@roeckx.be>
 <20180414.215441.596452434009486184.levitte@openssl.org>
Message-ID: <20180414200010.GB27858@roeckx.be>

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


From openssl-users at dukhovni.org  Sat Apr 14 20:01:42 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 14 Apr 2018 16:01:42 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180414.213231.903361400025235343.levitte@openssl.org>
References: <20180414.213231.903361400025235343.levitte@openssl.org>
Message-ID: <352EBAA2-B2D4-4A2E-ADC4-1033A1735ADC@dukhovni.org>



> On Apr 14, 2018, at 3:32 PM, Richard Levitte <levitte at openssl.org> wrote:
> 
> So regarding assumptions, there's only one assumption that I'm ready
> to make: a program that worked correctly with libssl 1.1.0 and uses
> its functionality as advertised should work the same with libssl
> 1.1.1.  Note that I'm not saying that this excludes new features
> "under the hood", but in that case, those new features should work
> transparently enough that a program doesn't need to be changed because
> of them.  Also, note again that I'm not talking about recompilation,
> but the implicit relinking that is what happens when a shared library
> is upgraded but keeps the same library version number (no "bump").
> (mind you, explicit relinking would make no different in this regard).
> 
> Does anyone disagree with that assumption?

It must be possible to upgrade from 1.1.0 to 1.1.1 without source
code changes, or relinking the program.  From what you describe,
it seems that source code changes might be needed to adapt to
a TLS-1.3-capable library.  That should not happen.

> 1. There's the option of making the new release 1.2.0 instead of 1.1.1.
>   I think most of us aren't keen on this, but it has to be said.

This does not address the issue of yet another compatibility break, with
many distributions not yet done adopting 1.1.0.  So I don't see that
as a solution.

> 2. Make TLSv1.2 the absolutely maximum TLS version available for
>   programs linked with libssl 1.1.0.  This is what's done in this PR:
>   https://github.com/openssl/openssl/pull/5945
>   This makes sense insofar that it's safe, it works within the known
>   parameters for the library these programs were built for.
>   It also makes sense if we view TLSv1.3 as new functionality, and
>   new functionality is usually only available to those who
>   explicitely build their programs for the new library version.
>   TLSv1.3 is unusual in this sense because it's at least it great
>   part "under the hood", just no 100% transparently so.

This should NOT be necessary.  What it is about enabling TLS 1.3
that breaks existing code?  Let's fix that.

> 3. ....  I dunno, please share ideas if you have them.

We need to make sure that the introduction of TLS 1.3 is transparent,
aside from occasionally leading to a connection that uses TLS 1.3.

If all that's failing is our test-suite, which is too sensitive to the
underlying implementation details, that's fine, not all the tests are 
designed to run cross-library.

Will real applications run into any meaningful problems?

While can artificially limit the max protocol in applications compiled
for 1.1.0, I don't think that's a compelling design choice.  We have
support in 1.1.0 for min/max protocol, applications can use those
controls explicitly.

In any case in order of preference, I'd like to see:

  1. Fix any issues so that it is safe to upgrade.
  2. Make the library version 1.2
  3. Hack the API to cap the protocol version based on compile-time
     maximum.

-- 
-- 
	Viktor.


From rsalz at akamai.com  Sat Apr 14 20:11:12 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 14 Apr 2018 20:11:12 +0000
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <352EBAA2-B2D4-4A2E-ADC4-1033A1735ADC@dukhovni.org>
References: <20180414.213231.903361400025235343.levitte@openssl.org>
 <352EBAA2-B2D4-4A2E-ADC4-1033A1735ADC@dukhovni.org>
Message-ID: <8F4869F1-F9A1-479B-8A94-8A45D8255447@akamai.com>

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.

 


From levitte at openssl.org  Sat Apr 14 20:18:15 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 14 Apr 2018 22:18:15 +0200 (CEST)
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <352EBAA2-B2D4-4A2E-ADC4-1033A1735ADC@dukhovni.org>
References: <20180414.213231.903361400025235343.levitte@openssl.org>
 <352EBAA2-B2D4-4A2E-ADC4-1033A1735ADC@dukhovni.org>
Message-ID: <20180414.221815.1002430664439994502.levitte@openssl.org>

In message <352EBAA2-B2D4-4A2E-ADC4-1033A1735ADC at dukhovni.org> on Sat, 14 Apr 2018 16:01:42 -0400, Viktor Dukhovni <openssl-users at dukhovni.org> said:

openssl-users> > 2. Make TLSv1.2 the absolutely maximum TLS version available for
openssl-users> >   programs linked with libssl 1.1.0.  This is what's done in this PR:
openssl-users> >   https://github.com/openssl/openssl/pull/5945
openssl-users> >   This makes sense insofar that it's safe, it works within the known
openssl-users> >   parameters for the library these programs were built for.
openssl-users> >   It also makes sense if we view TLSv1.3 as new functionality, and
openssl-users> >   new functionality is usually only available to those who
openssl-users> >   explicitely build their programs for the new library version.
openssl-users> >   TLSv1.3 is unusual in this sense because it's at least it great
openssl-users> >   part "under the hood", just no 100% transparently so.
openssl-users> 
openssl-users> This should NOT be necessary.  What it is about enabling TLS 1.3
openssl-users> that breaks existing code?  Let's fix that.

I'm not savvy enough to answer that properly.  I'm mostly observing
from the exterior.

openssl-users> > 3. ....  I dunno, please share ideas if you have them.
openssl-users> 
openssl-users> We need to make sure that the introduction of TLS 1.3 is transparent,
openssl-users> aside from occasionally leading to a connection that uses TLS 1.3.
openssl-users> 
openssl-users> If all that's failing is our test-suite, which is too sensitive to the
openssl-users> underlying implementation details, that's fine, not all the tests are 
openssl-users> designed to run cross-library.
openssl-users> 
openssl-users> Will real applications run into any meaningful problems?

This is an argument that I find *terribly* frustrating.  Are you
suggesting that we have no test that tries to do what can be expect
from a "real" application?  What do you expect a "real" application to
limit itself to?  Do you expect a "real" application to always set a
maximum TLS version?  Do you expect a "real" application to expect
failure because it hasn't?  Was any of the limitations you might think
of advertised?  In the 1.1.0 manual pages?  Elsewhere?

Also, I imagine that test_ssl_old, test_ssl_new and test_sslapi are
three tests that do try to mimic "real world" use of libssl.

openssl-users> While can artificially limit the max protocol in applications compiled
openssl-users> for 1.1.0, I don't think that's a compelling design choice.  We have
openssl-users> support in 1.1.0 for min/max protocol, applications can use those
openssl-users> controls explicitly.

Yes, they can, but they won't necessarely.  Just as an example, our
1.1.0 test programs didn't before I stoopidly made them do so (I'm
reverting that with https://github.com/openssl/openssl/pull/5947,
because it was an enormously stoopid move that only showed that an
upgrade to 1.1.1 *required* at least the addition of such controls)

openssl-users> In any case in order of preference, I'd like to see:
openssl-users> 
openssl-users>   1. Fix any issues so that it is safe to upgrade.
openssl-users>   2. Make the library version 1.2
openssl-users>   3. Hack the API to cap the protocol version based on compile-time
openssl-users>      maximum.
openssl-users> 
openssl-users> -- 
openssl-users> -- 
openssl-users> 	Viktor.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From openssl-users at dukhovni.org  Sat Apr 14 20:24:56 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 14 Apr 2018 16:24:56 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180414.221815.1002430664439994502.levitte@openssl.org>
References: <20180414.213231.903361400025235343.levitte@openssl.org>
 <352EBAA2-B2D4-4A2E-ADC4-1033A1735ADC@dukhovni.org>
 <20180414.221815.1002430664439994502.levitte@openssl.org>
Message-ID: <44FE0745-31DF-41C3-B697-97025643CE32@dukhovni.org>



> On Apr 14, 2018, at 4:18 PM, Richard Levitte <levitte at openssl.org> wrote:
> 
>> Will real applications run into any meaningful problems?
> 
> This is an argument that I find *terribly* frustrating.  Are you
> suggesting that we have no test that tries to do what can be expect
> from a "real" application?

I am suggesting that we ignore test failures that test for rather
artificial conditions.  If our test negotiates TLS with our own
server and tests that it got exactly TLS 1.2 (because that's the
highest version our test expected to support by default) that's an
artificial test, and its failure is fine.  Real applications that
want no more than TLS 1.2 need to set the max version, or not expect
that maximum.  Anything else is an application bug.

Do we have any meaningful test failures that are not artificial like
the above?  If so, we should fix them, if not we possibly need more
tests, but are otherwise fine as best we know.

-- 
	Viktor.


From levitte at openssl.org  Sat Apr 14 20:40:11 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 14 Apr 2018 22:40:11 +0200 (CEST)
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <44FE0745-31DF-41C3-B697-97025643CE32@dukhovni.org>
References: <352EBAA2-B2D4-4A2E-ADC4-1033A1735ADC@dukhovni.org>
 <20180414.221815.1002430664439994502.levitte@openssl.org>
 <44FE0745-31DF-41C3-B697-97025643CE32@dukhovni.org>
Message-ID: <20180414.224011.35582083635363605.levitte@openssl.org>

In message <44FE0745-31DF-41C3-B697-97025643CE32 at dukhovni.org> on Sat, 14 Apr 2018 16:24:56 -0400, Viktor Dukhovni <openssl-users at dukhovni.org> said:

openssl-users> 
openssl-users> 
openssl-users> > On Apr 14, 2018, at 4:18 PM, Richard Levitte <levitte at openssl.org> wrote:
openssl-users> > 
openssl-users> >> Will real applications run into any meaningful problems?
openssl-users> > 
openssl-users> > This is an argument that I find *terribly* frustrating.  Are you
openssl-users> > suggesting that we have no test that tries to do what can be expect
openssl-users> > from a "real" application?
openssl-users> 
openssl-users> I am suggesting that we ignore test failures that test for rather
openssl-users> artificial conditions.  If our test negotiates TLS with our own
openssl-users> server and tests that it got exactly TLS 1.2 (because that's the
openssl-users> highest version our test expected to support by default) that's an
openssl-users> artificial test, and its failure is fine.

Do all the tests do that, i.e. actually check that they got nothing
higher than TLSv1.2?  This is an open question, I haven't dived enough
into the TLS stuff to know (but will next week unless someone can say
for sure).  If that is the case, then I agree that it's quite
artificial.  Otherwise, not so much.

openssl-users> Real applications that want no more than TLS 1.2 need
openssl-users> to set the max version, or not expect that maximum.
openssl-users> Anything else is an application bug.

Would you say that it's an application bug if it stumbles on a change
in API behavior that isn't due to a bug fix?  (and even better, if it
worked according to documentation?)

openssl-users> Do we have any meaningful test failures that are not
openssl-users> artificial like the above?  If so, we should fix them,
openssl-users> if not we possibly need more tests, but are otherwise
openssl-users> fine as best we know.

I disagree with us being fine, unless the possible issue I'm raising
can be disqualified with certainty.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From openssl-users at dukhovni.org  Sat Apr 14 20:46:56 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 14 Apr 2018 16:46:56 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180414.224011.35582083635363605.levitte@openssl.org>
References: <352EBAA2-B2D4-4A2E-ADC4-1033A1735ADC@dukhovni.org>
 <20180414.221815.1002430664439994502.levitte@openssl.org>
 <44FE0745-31DF-41C3-B697-97025643CE32@dukhovni.org>
 <20180414.224011.35582083635363605.levitte@openssl.org>
Message-ID: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>



> On Apr 14, 2018, at 4:40 PM, Richard Levitte <levitte at openssl.org> wrote:
> 
> Would you say that it's an application bug if it stumbles on a change
> in API behavior that isn't due to a bug fix?  (and even better, if it
> worked according to documentation?)

Negotiating a new version of TLS is not a change in API behaviour.  The
application asks for a TLS session (of no particular maximum version),
and it gets one that both the client library and the peer support.

I just tested posttls-finger compiled for 1.1.0 running with a 1.1.1
library against a TLS 1.2 server and it worked fine.

What version of OpenSSL is Postfix linked against on mta.openssl.org?
Care to upgrade it to 1.1.0 if not already?  Then replace the libraries
with the 1.1.1 versions?  I can then retest...

Running an MTA built for 1.1.0 against 1.1.1 libraries might be a reasonable
way to "eat our own dog food".

-- 
	Viktor.


From levitte at openssl.org  Sat Apr 14 21:09:17 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sat, 14 Apr 2018 23:09:17 +0200 (CEST)
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
References: <44FE0745-31DF-41C3-B697-97025643CE32@dukhovni.org>
 <20180414.224011.35582083635363605.levitte@openssl.org>
 <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
Message-ID: <20180414.230917.75972276947889430.levitte@openssl.org>

In message <D371758F-1CB0-48E5-8590-48094B2A8EF8 at dukhovni.org> on Sat, 14 Apr 2018 16:46:56 -0400, Viktor Dukhovni <openssl-users at dukhovni.org> said:

openssl-users> > On Apr 14, 2018, at 4:40 PM, Richard Levitte <levitte at openssl.org> wrote:
openssl-users> > 
openssl-users> > Would you say that it's an application bug if it stumbles on a change
openssl-users> > in API behavior that isn't due to a bug fix?  (and even better, if it
openssl-users> > worked according to documentation?)
openssl-users> 
openssl-users> Negotiating a new version of TLS is not a change in API behaviour.  The
openssl-users> application asks for a TLS session (of no particular maximum version),
openssl-users> and it gets one that both the client library and the peer support.
openssl-users> 
openssl-users> I just tested posttls-finger compiled for 1.1.0 running with a 1.1.1
openssl-users> library against a TLS 1.2 server and it worked fine.

Does this answer the whole question, or do they just do the most basic
stuff that our public headers make available?

To put it another way, I would absolutely hate it if, after 1.1.1
(assuming that's what we go for) is released, people came back
screaming at us because their program toppled over or bailed out in a
virtual panic attack just because of a shared library upgrade.
I would prefer if we treated this with *certainties* rather than
*probabilities*, and for the moment, it feels like I'm being fed with
the latter rather than the former.

openssl-users> What version of OpenSSL is Postfix linked against on mta.openssl.org?
openssl-users> Care to upgrade it to 1.1.0 if not already?  Then replace the libraries
openssl-users> with the 1.1.1 versions?  I can then retest...

mta.openssl.org runs Ubuntu 16.04 and the as up to date packages as I
get.  I prefer to run things with vendor packages, so we have an easy
path for updates, and considering that's our central mail hub, I'm not
at all keen on potentially screwing things up there.

But tell you what, there's a test machine as well, which I did set up
specifically for trying this sort of thing.  I can certainly screw
around with all of that there.

openssl-users> Running an MTA built for 1.1.0 against 1.1.1 libraries
openssl-users> might be a reasonable way to "eat our own dog food".

Yeeeaaaahhh, ya know, I do believe in eating your own dog food, but
only to a level.  Central production machinery that we all depend on
is a big no-no in my admin brain.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/


From rsalz at akamai.com  Sat Apr 14 21:13:47 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 14 Apr 2018 21:13:47 +0000
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180414.230917.75972276947889430.levitte@openssl.org>
References: <44FE0745-31DF-41C3-B697-97025643CE32@dukhovni.org>
 <20180414.224011.35582083635363605.levitte@openssl.org>
 <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
Message-ID: <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>

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 work *going forwards* ?



From openssl-users at dukhovni.org  Sat Apr 14 21:19:09 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 14 Apr 2018 17:19:09 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180414.230917.75972276947889430.levitte@openssl.org>
References: <44FE0745-31DF-41C3-B697-97025643CE32@dukhovni.org>
 <20180414.224011.35582083635363605.levitte@openssl.org>
 <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
Message-ID: <726A064A-2213-41C4-96BE-16570DBC2104@dukhovni.org>



> On Apr 14, 2018, at 5:09 PM, Richard Levitte <levitte at openssl.org> wrote:
> 
>> I just tested posttls-finger compiled for 1.1.0 running with a 1.1.1
>> library against a TLS 1.2 server and it worked fine.
> 
> Does this answer the whole question, or do they just do the most basic
> stuff that our public headers make available?

No mere test constitutes a formal proof of correctness.  I'm just saying
that compile-time 1.1.0 runs fine in routine SSL sessions with 1.1.1 as
the underlying library.  The posttls-finger program is comparatively
sophisticated in its use of SSL, but by no means tests the entire API.

> To put it another way, I would absolutely hate it if, after 1.1.1
> (assuming that's what we go for) is released, people came back
> screaming at us because their program toppled over or bailed out in a
> virtual panic attack just because of a shared library upgrade.

When support for TLS 1.2 appeared in OpenSSL, some Postfix users ran
into some trouble, with middle-boxes or some such and had to cap the
TLS version at TLS 1.0.  This happened some time between 1.0.0 and
1.0.2 IIRC, with the library ABI at 1.0.  This is to be expected.
No matter what we do some users will upgrade their applications and/or
OpenSSL library and find that they run into some friction with TLS 1.3.
None of our work-arounds will make the problem go away.  They'll just
have to deal with it.

> openssl-users> What version of OpenSSL is Postfix linked against on mta.openssl.org?
> openssl-users> Care to upgrade it to 1.1.0 if not already?  Then replace the libraries
> openssl-users> with the 1.1.1 versions?  I can then retest...
> 
> But tell you what, there's a test machine as well, which I did set up
> specifically for trying this sort of thing.  I can certainly screw
> around with all of that there.

A test machine would be great.

-- 
	Viktor.


From openssl-users at dukhovni.org  Sat Apr 14 21:21:35 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 14 Apr 2018 17:21:35 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
References: <44FE0745-31DF-41C3-B697-97025643CE32@dukhovni.org>
 <20180414.224011.35582083635363605.levitte@openssl.org>
 <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
Message-ID: <93A779CC-393C-45AB-80F2-FC20907AC0D3@dukhovni.org>



> On Apr 14, 2018, at 5:13 PM, Salz, Rich <rsalz at akamai.com> wrote:
> 
> 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.  However, the tests that I
read about failing were testing artificial expectations that are only
appropriate for the same library as the tests.  The tests can be fixed
to make their expectations more explicit (by e.g. setting the max protocol
version to the largest supported by the corresponding library).

-- 
	Viktor.


From levitte at openssl.org  Sun Apr 15 05:38:48 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 15 Apr 2018 07:38:48 +0200 (CEST)
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
Message-ID: <20180415.073848.2255386938941879954.levitte@openssl.org>

In message <C60D8170-70CB-44A7-86BD-9463D1A021C3 at akamai.com> on Sat, 14 Apr 2018 21:13:47 +0000, "Salz, Rich" <rsalz at akamai.com> 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.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From openssl-users at dukhovni.org  Sun Apr 15 05:53:08 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 15 Apr 2018 01:53:08 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180415.073848.2255386938941879954.levitte@openssl.org>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <20180415.073848.2255386938941879954.levitte@openssl.org>
Message-ID: <508D88C5-9604-4441-86D6-8CC137E04717@dukhovni.org>



> On Apr 15, 2018, at 1:38 AM, Richard Levitte <levitte at openssl.org> wrote:
> 
> 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.

It think it is most prudent to not fall into the trap of debating this
particular side-issue.  I commend your initiative of running the 1.1.0
tests against the 1.1.1 libraries, that's fantastic.  And I further
commend attention to the failure cases.  Thank you.

With that out of the way, it seems to me that apart from some fixes in
the test framework, and tests that did not expect protocol versions
higher than TLS 1.2, no *interesting* issues have turned up.

If such issue did or will turn up let's fix them, but there should not
be fundamental obstacles to an ABI-compatible 1.1.1 library with the
same SONAME as its 1.1.0 predecessor.  The new library may negotiate
TLS 1.3 which 1.1.0 did not, but I don't see that as an incompatibility
that requires an SONAME version bump.

Which is not to say I could not be convinced otherwise, but at present
I don't see a need for the bump, or for work-arounds to limit the
negotiated protocols for code compiled against 1.1.0 that happens to
run against 1.1.1.

Let's stay alert, but not overreact to minor issues we can resolve.

-- 
	Viktor.


From bernd.edlinger at hotmail.de  Sun Apr 15 06:24:48 2018
From: bernd.edlinger at hotmail.de (Bernd Edlinger)
Date: Sun, 15 Apr 2018 06:24:48 +0000
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <508D88C5-9604-4441-86D6-8CC137E04717@dukhovni.org>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <20180415.073848.2255386938941879954.levitte@openssl.org>
 <508D88C5-9604-4441-86D6-8CC137E04717@dukhovni.org>
Message-ID: <AM5PR0701MB265783557331E9B4355D0629E4B10@AM5PR0701MB2657.eurprd07.prod.outlook.com>

On 04/15/18 07:53, Viktor Dukhovni wrote:
> 
> 
>> On Apr 15, 2018, at 1:38 AM, Richard Levitte <levitte at openssl.org> wrote:
>>
>> 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.
> 
> It think it is most prudent to not fall into the trap of debating this
> particular side-issue.  I commend your initiative of running the 1.1.0
> tests against the 1.1.1 libraries, that's fantastic.  And I further
> commend attention to the failure cases.  Thank you.
> 
> With that out of the way, it seems to me that apart from some fixes in
> the test framework, and tests that did not expect protocol versions
> higher than TLS 1.2, no *interesting* issues have turned up.
> 
> If such issue did or will turn up let's fix them, but there should not
> be fundamental obstacles to an ABI-compatible 1.1.1 library with the
> same SONAME as its 1.1.0 predecessor.  The new library may negotiate
> TLS 1.3 which 1.1.0 did not, but I don't see that as an incompatibility
> that requires an SONAME version bump.
> 
> Which is not to say I could not be convinced otherwise, but at present
> I don't see a need for the bump, or for work-arounds to limit the
> negotiated protocols for code compiled against 1.1.0 that happens to
> run against 1.1.1.
> 
> Let's stay alert, but not overreact to minor issues we can resolve.
> 

One possible example of application failure that I am aware of is #5743:
A certificate that is incompatible with TLS1.3 but works with TLS1.2.
Admittedly that I did come up with that scenario only because I saw
a possible issue per code inspection.


Bernd.

From kurt at roeckx.be  Sun Apr 15 09:22:54 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 15 Apr 2018 11:22:54 +0200
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180415.073848.2255386938941879954.levitte@openssl.org>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <20180415.073848.2255386938941879954.levitte@openssl.org>
Message-ID: <20180415092253.GA3350@roeckx.be>

On Sun, Apr 15, 2018 at 07:38:48AM +0200, Richard Levitte wrote:
> In message <C60D8170-70CB-44A7-86BD-9463D1A021C3 at akamai.com> on Sat, 14 Apr 2018 21:13:47 +0000, "Salz, Rich" <rsalz at akamai.com> 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


From appro at openssl.org  Sun Apr 15 11:27:15 2018
From: appro at openssl.org (Andy Polyakov)
Date: Sun, 15 Apr 2018 13:27:15 +0200
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180414.213231.903361400025235343.levitte@openssl.org>
References: <20180414.213231.903361400025235343.levitte@openssl.org>
Message-ID: <ac42d34d-4ad9-3646-19a9-e9e3521d615a@openssl.org>

> 2. Make TLSv1.2 the absolutely maximum TLS version available for
>    programs linked with libssl 1.1.0.  This is what's done in this PR:
>    https://github.com/openssl/openssl/pull/5945
>    This makes sense insofar that it's safe, it works within the known
>    parameters for the library these programs were built for.

Here is a thing. If we assume that 110/test/sslapitest.c is
*representative* example of an 1.1.0 application, then it's not at all
given that #5945 would actually solve anything. Indeed, observing the
first failing test, recompiled 110/test/sslapitest.c would still fail,
because it makes assumption that session id is available right after
negotiation, something that doesn't hold true for TLS 1.3. This gives
you either a) no 1.1.0 application goes safe, recompiled[!] or not; b)
110/test/sslapitest.c is not representative example. Well, as far as
first failing test goes, I'd say it's b), which means that it should be
adjusted in one way or another or failing check omitted. [It's b),
because it's unnatural to put session id you've just got back to id
cache, the test is ultimately synthetic.] This naturally doesn't answer
all the questions, but it does show that above mentioned premise is
somewhat flawed. I mean "programs were built for [1.1.0]" would still
work if recompiled with #5945.

>    It also makes sense if we view TLSv1.3 as new functionality, and
>    new functionality is usually only available to those who
>    explicitely build their programs for the new library version.
>    TLSv1.3 is unusual in this sense because it's at least it great
>    part "under the hood", just no 100% transparently so.

In such case it should rather be #ifdef OPENSSL_ENABLE_TLS1_3 instead of
#ifndef OPENSSL_DISABLE_TLS1_3. And we don't want that.

To summarize, failing tests in 110 should be revisited to see if they
are actually representative, before one can consider as drastic measures
as #5945.

From levitte at openssl.org  Sun Apr 15 11:49:29 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 15 Apr 2018 13:49:29 +0200 (CEST)
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <ac42d34d-4ad9-3646-19a9-e9e3521d615a@openssl.org>
References: <20180414.213231.903361400025235343.levitte@openssl.org>
 <ac42d34d-4ad9-3646-19a9-e9e3521d615a@openssl.org>
Message-ID: <20180415.134929.564430745296199664.levitte@openssl.org>

In message <ac42d34d-4ad9-3646-19a9-e9e3521d615a at openssl.org> on Sun, 15 Apr 2018 13:27:15 +0200, Andy Polyakov <appro at openssl.org> said:

appro> To summarize, failing tests in 110 should be revisited to see if they
appro> are actually representative, before one can consider as drastic measures
appro> as #5945.

At this point, I agree.  Viktor's look at several applications and
Kurt's report of successful did convince me that I might by crying
wolf a bit much.  I've started looking a bit deeper at the failing
tests, for exactly the reasons you mention.

Now, there was a point brought on by a couple of issues mentioned,
I'll take that in a separate email.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Sun Apr 15 12:07:25 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 15 Apr 2018 14:07:25 +0200 (CEST)
Subject: [openssl-project] Proto over ciphers or ciphers over proto? (was:
 The problem of (implicit) relinking and changed behaviour)
In-Reply-To: <AM5PR0701MB265783557331E9B4355D0629E4B10@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <20180415.073848.2255386938941879954.levitte@openssl.org>
 <508D88C5-9604-4441-86D6-8CC137E04717@dukhovni.org>
 <AM5PR0701MB265783557331E9B4355D0629E4B10@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <20180415.140725.273150327667322919.levitte@openssl.org>

In message <AM5PR0701MB265783557331E9B4355D0629E4B10 at AM5PR0701MB2657.eurprd07.prod.outlook.com> on Sun, 15 Apr 2018 06:24:48 +0000, Bernd Edlinger <bernd.edlinger at hotmail.de> said:

bernd.edlinger> One possible example of application failure that I am aware of is #5743:
bernd.edlinger> A certificate that is incompatible with TLS1.3 but works with TLS1.2.
bernd.edlinger> Admittedly that I did come up with that scenario only because I saw
bernd.edlinger> a possible issue per code inspection.

This touches an issue that's already mentioned in Matt's blog, and I
gotta ask how the protocols so be presented for negotiation are chosen
(yes, I know, I could dive into the code...  and I will unless there's
a quick answer).  Does libssl just pick the max version chosen (within
the range that we support unless the application has narrowed it
down), or does it also look at other facts, such as chosen server or
client certs to see what protocol version range would actually work
with those collected facts?  #5743 seems to say that libssl doesn't
look at such facts, and can end up in the absurd situation that things
stop working because it selected TLSv1.3 over TLSv1.2 when the latter
couldn't possibly work right, while TLSv1.2 does.

I can't really say what's right or wrong in this case, this really is
a philosophical question more than anything else.  Is it all right to
just pick a proto version that cannot work and then virtually flip it
to the unsuspecting application that wasn't prepared with better data
(such as a cert that's also valid in TLSv1.3) or is that essentially
wrong, even though easier to deal with in code?  Is that what libssl
is doing, or does it have more of a "look at all the facts" approach
before choosing the proto range to negotiate with the other end?

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From openssl-users at dukhovni.org  Sun Apr 15 16:15:55 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 15 Apr 2018 12:15:55 -0400
Subject: [openssl-project] Proto over ciphers or ciphers over proto?
 (was: The problem of (implicit) relinking and changed behaviour)
In-Reply-To: <20180415.140725.273150327667322919.levitte@openssl.org>
References: <20180415.073848.2255386938941879954.levitte@openssl.org>
 <508D88C5-9604-4441-86D6-8CC137E04717@dukhovni.org>
 <AM5PR0701MB265783557331E9B4355D0629E4B10@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180415.140725.273150327667322919.levitte@openssl.org>
Message-ID: <8A8AF89D-69BB-4CE6-A288-CE6614F593A4@dukhovni.org>



> On Apr 15, 2018, at 8:07 AM, Richard Levitte <levitte at openssl.org> wrote:
> 
> This touches an issue that's already mentioned in Matt's blog, and I
> gotta ask how the protocols so be presented for negotiation are chosen
> (yes, I know, I could dive into the code...  and I will unless there's
> a quick answer).  Does libssl just pick the max version chosen (within
> the range that we support unless the application has narrowed it
> down), or does it also look at other facts, such as chosen server or
> client certs to see what protocol version range would actually work
> with those collected facts?  #5743 seems to say that libssl doesn't
> look at such facts, and can end up in the absurd situation that things
> stop working because it selected TLSv1.3 over TLSv1.2 when the latter
> couldn't possibly work right, while TLSv1.2 does.
> 
> I can't really say what's right or wrong in this case, this really is
> a philosophical question more than anything else.  Is it all right to
> just pick a proto version that cannot work and then virtually flip it
> to the unsuspecting application that wasn't prepared with better data
> (such as a cert that's also valid in TLSv1.3) or is that essentially
> wrong, even though easier to deal with in code?  Is that what libssl
> is doing, or does it have more of a "look at all the facts" approach
> before choosing the proto range to negotiate with the other end?

I'd support choosing a lower protocol version when no interoperable
parameters are available to complete the handshake at a higher version,
but that's rather complex, and we've never done that, so I don't see
that happening on short notice, it would require some design, review
and testing time we don't have before the upcoming release.

That said, I'm puzzled by the notion of "A certificate that is incompatible
with TLS1.3".  A certificate is a certificate, and introducing TLS 1.3 does
not in any change the validity of the certificate, TLS 1.3 did not rewrite
RFC5280.  So if there's a certificate we're disallowing with TLS 1.3, that's
a bug we need to fix.  If anything TLS 1.3 is supposed to be more liberal in
how certificates are processed, since it no longer (former bug in the TLS 1.2
spec) mandates that the server hang up when the clients sigalgs don't match
the server chain, just present what you have, and let the client decide.

The specific issue cited is a bug in our TLS 1.3 implementation, the server
must NEVER refuse to present at least some default certificate chain when
it can't find one that exactly matches the client's signalled algorithms.

The EC point representation in the TLS 1.3 ECDHE key exchange messages must be uncompressed, but this has no bearing on PKIX, any TLS messages that require
signing just get signed per X.509, the TLS point formats have nothing to do
with this.  In Section 4.2.3 of the TLS 1.3 draft we have:

   ECDSA algorithms  Indicates a signature algorithm using ECDSA
      [ECDSA], the corresponding curve as defined in ANSI X9.62 [X962]
      and FIPS 186-4 [DSS], and the corresponding hash algorithm as
      defined in [SHS].  The signature is represented as a DER-encoded
      [X690] ECDSA-Sig-Value structure.

We should always keep in mind the semantic separation between PKIX and
TLS.  For a memorable if poorly fitting quip:

	Render unto Caesar the things that are Caesar's,
        and unto God the things that are God's

now you just to figure out which is which... :-)

-- 
	Viktor.


From openssl-users at dukhovni.org  Sun Apr 15 16:18:48 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 15 Apr 2018 12:18:48 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <AM5PR0701MB265783557331E9B4355D0629E4B10@AM5PR0701MB2657.eurprd07.prod.outlook.com>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <20180415.073848.2255386938941879954.levitte@openssl.org>
 <508D88C5-9604-4441-86D6-8CC137E04717@dukhovni.org>
 <AM5PR0701MB265783557331E9B4355D0629E4B10@AM5PR0701MB2657.eurprd07.prod.outlook.com>
Message-ID: <7C84EC32-0158-47D6-AF22-4C96659EADEB@dukhovni.org>



> On Apr 15, 2018, at 2:24 AM, Bernd Edlinger <bernd.edlinger at hotmail.de> wrote:
> 
> One possible example of application failure that I am aware of is #5743:
> A certificate that is incompatible with TLS1.3 but works with TLS1.2.
> Admittedly that I did come up with that scenario only because I saw
> a possible issue per code inspection.

[ Repeating in part my response to Richar's mesage also in this thread ]

This is a bug that needs to be fixed, the point format for TLS does not
have any provenance over X.509.  There's no such thing as a certificate
not compatible with TLS 1.3 (that is compatible with TLS 1.2).

-- 
	Viktor.


From rsalz at akamai.com  Sun Apr 15 16:55:55 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 15 Apr 2018 16:55:55 +0000
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <93A779CC-393C-45AB-80F2-FC20907AC0D3@dukhovni.org>
References: <44FE0745-31DF-41C3-B697-97025643CE32@dukhovni.org>
 <20180414.224011.35582083635363605.levitte@openssl.org>
 <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <93A779CC-393C-45AB-80F2-FC20907AC0D3@dukhovni.org>
Message-ID: <86D6F123-0CDC-4A30-8B31-95570BAC23A0@akamai.com>

    > 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.  However, the tests that I
    read about failing were testing artificial expectations that are only
    appropriate for the same library as the tests.  The tests can be fixed
    to make their expectations more explicit (by e.g. setting the max protocol
    version to the largest supported by the corresponding library).
  
Good point.  I meant our 1.1.1 tests don't completely work when linked with 1.1.0 library.  I am not surprised about that as I am sure there are all sorts of hidden assumptions in the 1.1.1 tests.  Now it seems to turn out that there are only a couple of assumptions, and that maybe we can fix them.  As I said initially, I don't see that as worth any effort, but others are free to disagree and have.

Do our 1.1.0 tests work when linked against the 1.1.1 library?  Even then, there might be some failures because some of those tests probably say "pick any protocol" and they were written at a time when 1.3 was not available so might explicitly test, for example, that "any protocol" meant "got 1.2"  It would be interesting to test 1.1.0 against the 1.1.1 library, and then analyze the failures and see which, if any, indicate bugs in the 1.1.1 compatibility.

Again, to repeat myself, we have datapoints that 1.1.0 programs can use 1.1.1 library with no problems. We do not have any datapoints that typical 1.1.0 programs fail when using 1.1.1 library. 


From rsalz at akamai.com  Sun Apr 15 16:59:10 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 15 Apr 2018 16:59:10 +0000
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180415.073848.2255386938941879954.levitte@openssl.org>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <20180415.073848.2255386938941879954.levitte@openssl.org>
Message-ID: <44330644-C5DD-4E81-869E-3B1597207A4E@akamai.com>

    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?

Our s_client and s_server just work. Viktor said postfix just works.  I have seen reports that Apache just works. Someone reported python crypto just works.

Let me turn the question around because we'll never know "everything" just works.  Except for our tests, what programs work with 1.1.0 and *fail* to work with 1.1.1?  Any?  For various reasons that Viktor and I have detailed, *our tests* do not count.
 


From openssl-users at dukhovni.org  Sun Apr 15 17:01:48 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 15 Apr 2018 13:01:48 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <86D6F123-0CDC-4A30-8B31-95570BAC23A0@akamai.com>
References: <44FE0745-31DF-41C3-B697-97025643CE32@dukhovni.org>
 <20180414.224011.35582083635363605.levitte@openssl.org>
 <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <93A779CC-393C-45AB-80F2-FC20907AC0D3@dukhovni.org>
 <86D6F123-0CDC-4A30-8B31-95570BAC23A0@akamai.com>
Message-ID: <7F81FCAB-F691-4410-B8D7-64C38738B47D@dukhovni.org>



> On Apr 15, 2018, at 12:55 PM, Salz, Rich <rsalz at akamai.com> wrote:
> 
> Do our 1.1.0 tests work when linked against the 1.1.1 library?

Our tests don't, but Richard (valiantly I must say) went to the trouble
of doing just that.  And found some tests that failed, ...

> Even then, there might be some failures because some of those tests probably say "pick any protocol" and they were written at a time when 1.3 was not available so might explicitly test, for example, that "any protocol" meant "got 1.2"

in particular this type of failure.

> It would be interesting to test 1.1.0 against the 1.1.1 library, and then analyze the failures and see which, if any, indicate bugs in the 1.1.1 compatibility.

This is what Richard was doing, and I commend his efforts.

> Again, to repeat myself, we have datapoints that 1.1.0 programs can use 1.1.1 library with no problems. We do not have any datapoints that typical 1.1.0 programs fail when using 1.1.1 library. 

I think that tests of this sort are valuable, and should in some cases make the test's assumptions more explicit, so that they will also pass with later libraries.  Then we can focus on any "real" issues that come up, and decide whether they are bugs, significant incompatibilities or "artificial" issues not substantive for "real" applications.

-- 
	Viktor.


From openssl-users at dukhovni.org  Sun Apr 15 17:04:12 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 15 Apr 2018 13:04:12 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <44330644-C5DD-4E81-869E-3B1597207A4E@akamai.com>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <20180415.073848.2255386938941879954.levitte@openssl.org>
 <44330644-C5DD-4E81-869E-3B1597207A4E@akamai.com>
Message-ID: <F6EED802-4C13-40A1-A16A-B40E751A327D@dukhovni.org>



> On Apr 15, 2018, at 12:59 PM, Salz, Rich <rsalz at akamai.com> wrote:
> 
> Let me turn the question around because we'll never know "everything" just works. Except for our tests, what programs work with 1.1.0 and *fail* to work with 1.1.1?  Any? For various reasons that Viktor and I have detailed, *our tests* do not count.

I would not go as far as that.  Our tests do count, and should be paid attention to, but we need to be careful about interpreting the results.  Sometimes the answer is to tune the test to make it portable to later library versions.  So far, we've not seen issues that warrant a library version bump, but testing this is a good idea, and Richard is doing good work.

-- 
	Viktor.


From tjh at cryptsoft.com  Sun Apr 15 17:13:27 2018
From: tjh at cryptsoft.com (Tim Hudson)
Date: Sun, 15 Apr 2018 10:13:27 -0700
Subject: [openssl-project] The problem of (implicit) relinking and
	changed behaviour
In-Reply-To: <F6EED802-4C13-40A1-A16A-B40E751A327D@dukhovni.org>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <20180415.073848.2255386938941879954.levitte@openssl.org>
 <44330644-C5DD-4E81-869E-3B1597207A4E@akamai.com>
 <F6EED802-4C13-40A1-A16A-B40E751A327D@dukhovni.org>
Message-ID: <CAHEJ-S5Tnh5uW3PZ-gHaSEMzN3_sSaNjndfxFc+D0yojR2m92g@mail.gmail.com>

Where we are stating that ABI compatibility is in place we should be
testing it.
i.e. the older release binaries should be run against the current release
libraries - and that should be put into CI in my view.

Going the other direction isn't something I have thought we have ever
guaranteed (i.e. downgrading) - but programs that don't use new APIs (i.e.
for the ABI) should also work - that is pretty much the definition of an
ABI.
If we are unable to provide the forward ABI then we need to change the
version number of the release going forward. If weare unable to provide
backwards ABI then we need to think about how we are defining things and
make that clear.

And we need to be clear about what we mean by ABI - I don't think we have
written down a clear definition - and then have in CI the tests to match
what we are saying we do.

When it comes to TLSv1.3 it is highly desirable that an existing 1.1.0
application gets TLSv1.3 without API changes - i.e. ABI provides this.
There will be some things where there are problems where assumptions are
invalidated - but we should work to minimise those (and I think we have
actually done so).
But again we should be testing this in CI - if we want old apps to all get
TLSv1.3 for zero effort (other than a shared library upgrade) then we
should test that in CI. Hoping it works or assuming it works and "manually"
watching for changes that might invalidate that is rather error prone.

What Richard is doing really helps add to the information for informed
decisions ... the more information we have the better in my view.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180415/0f632905/attachment-0001.html>

From rsalz at akamai.com  Sun Apr 15 17:15:42 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 15 Apr 2018 17:15:42 +0000
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <CAHEJ-S5Tnh5uW3PZ-gHaSEMzN3_sSaNjndfxFc+D0yojR2m92g@mail.gmail.com>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <20180415.073848.2255386938941879954.levitte@openssl.org>
 <44330644-C5DD-4E81-869E-3B1597207A4E@akamai.com>
 <F6EED802-4C13-40A1-A16A-B40E751A327D@dukhovni.org>
 <CAHEJ-S5Tnh5uW3PZ-gHaSEMzN3_sSaNjndfxFc+D0yojR2m92g@mail.gmail.com>
Message-ID: <3C125EE8-97CE-465D-A22D-C278CF1D7E05@akamai.com>

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 correct in saying that, so far, everything has been of that type?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180415/d40be07d/attachment.html>

From kaduk at mit.edu  Sun Apr 15 21:06:20 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Sun, 15 Apr 2018 16:06:20 -0500
Subject: [openssl-project] Proto over ciphers or ciphers over proto?
 (was: The problem of (implicit) relinking and changed behaviour)
In-Reply-To: <8A8AF89D-69BB-4CE6-A288-CE6614F593A4@dukhovni.org>
References: <20180415.073848.2255386938941879954.levitte@openssl.org>
 <508D88C5-9604-4441-86D6-8CC137E04717@dukhovni.org>
 <AM5PR0701MB265783557331E9B4355D0629E4B10@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180415.140725.273150327667322919.levitte@openssl.org>
 <8A8AF89D-69BB-4CE6-A288-CE6614F593A4@dukhovni.org>
Message-ID: <20180415210620.GA54168@kduck.kaduk.org>

On Sun, Apr 15, 2018 at 12:15:55PM -0400, Viktor Dukhovni wrote:
> 
> 
> That said, I'm puzzled by the notion of "A certificate that is incompatible
> with TLS1.3".  A certificate is a certificate, and introducing TLS 1.3 does
> not in any change the validity of the certificate, TLS 1.3 did not rewrite
> RFC5280.  So if there's a certificate we're disallowing with TLS 1.3, that's

IIUC a fixed DH certificate is incompatible with TLS 1.3 but can be
TLS 1.2-compatible.

-Ben

From kaduk at mit.edu  Sun Apr 15 21:20:37 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Sun, 15 Apr 2018 16:20:37 -0500
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180415.134929.564430745296199664.levitte@openssl.org>
References: <20180414.213231.903361400025235343.levitte@openssl.org>
 <ac42d34d-4ad9-3646-19a9-e9e3521d615a@openssl.org>
 <20180415.134929.564430745296199664.levitte@openssl.org>
Message-ID: <20180415212027.GB54168@kduck.kaduk.org>

On Sun, Apr 15, 2018 at 01:49:29PM +0200, Richard Levitte wrote:
> In message <ac42d34d-4ad9-3646-19a9-e9e3521d615a at openssl.org> on Sun, 15 Apr 2018 13:27:15 +0200, Andy Polyakov <appro at openssl.org> said:
> 
> appro> To summarize, failing tests in 110 should be revisited to see if they
> appro> are actually representative, before one can consider as drastic measures
> appro> as #5945.
> 
> At this point, I agree.  Viktor's look at several applications and
> Kurt's report of successful did convince me that I might by crying
> wolf a bit much.  I've started looking a bit deeper at the failing
> tests, for exactly the reasons you mention.

I'll echo the thanks going around for looking into the tests more
closely, and note that I'm happy to see that you are stepping back a
bit from the initial report -- it seems good be concerned, but I
don't think we have reason to panic quite yet.

Having said that, I'll step back a bit and try to speak to the
"philosophy" question from the start of the thread.  I think it is
good philosophy to worry about this sort of ABI stability, and agree
with Tim that it's good release engineering practice to have
automated tests for it (to the extent that we can).  What I'd like
us to think more about, though, is our release engineering in
general.  Don't get me wrong; we've made huge progess since the
1.0.2 era already, adding much more comprehensive test suite
(including external tests) and insisting that new features come with
tests and documentation.  But I still wonder if we could/should be
more aware of the release engineering consequences of our more daily
changes, at least when master is intended to be on a "stable ABI"
branch.

In the following examples, I'm not trying to point fingers or say
that we made mistakes; so far as I know these were all consistent
with our current policy and procedures.  That said, I have to wonder
if doing things like reverting old changes that we don't have CLAs
for, or introducing additional churn into the RNG, are the best idea
in this stage of the release cycle.  True, we're only in feature
freeze and not some final release freeze, but there is risk/reward
analysis to be done, and I just don't know how much we've been
thinking about that sort of tradeoff.  (I believe there are other
examples in a similar vein, but don't remember them off the top of
my head.)  I guess this can be summarized as "I don't have a good
understanding for what scale/size of change we as a group are
comfortable making during various stages of ABI compatibility and
release planning" -- I don't want to dictate policy, just start a
discussion (or at least gain a better understanding of existing
consensus).

I will note, though, that if we want to be very contemplative about
the release engineering and ABI stability consequences of changes
landing on an "ABI-stable" branch, that may end up leading to a
stronger argument for having master never be the "ABI-stable"
branch, so that it's always open for development work and we need
not do exhaustive analysis for *all* commits during some
months+-long period of time.  (There would then be a separate stable
branch, of course, and we'd do the extra "thinking" when merging to
it.)

-Ben

From openssl-users at dukhovni.org  Sun Apr 15 21:31:29 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 15 Apr 2018 17:31:29 -0400
Subject: [openssl-project] Proto over ciphers or ciphers over proto?
 (was: The problem of (implicit) relinking and changed behaviour)
In-Reply-To: <20180415210620.GA54168@kduck.kaduk.org>
References: <20180415.073848.2255386938941879954.levitte@openssl.org>
 <508D88C5-9604-4441-86D6-8CC137E04717@dukhovni.org>
 <AM5PR0701MB265783557331E9B4355D0629E4B10@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <20180415.140725.273150327667322919.levitte@openssl.org>
 <8A8AF89D-69BB-4CE6-A288-CE6614F593A4@dukhovni.org>
 <20180415210620.GA54168@kduck.kaduk.org>
Message-ID: <10815AF8-2F59-405D-9DB9-AACB1E74574F@dukhovni.org>



> On Apr 15, 2018, at 5:06 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
> 
> IIUC a fixed DH certificate is incompatible with TLS 1.3 but can be
> TLS 1.2-compatible.

Yes, you're right, TLS 1.3 dropped fixed-dh support, but we've a while back dropped support for all the (authenticated) corresponding TLS 1.2 ciphers!

  $ OpenSSL_master/bin/openssl ciphers -stdname -v ALL | grep _DH_ | awk '{print $1}'
  TLS_DH_anon_WITH_AES_256_GCM_SHA384
  TLS_DH_anon_WITH_AES_128_GCM_SHA256
  TLS_DH_anon_WITH_AES_256_CBC_SHA256
  TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
  TLS_DH_anon_WITH_AES_128_CBC_SHA256
  TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
  TLS_DH_anon_WITH_AES_256_CBC_SHA
  TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA
  TLS_DH_anon_WITH_AES_128_CBC_SHA
  TLS_DH_anon_WITH_SEED_CBC_SHA
  TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA

We should perhaps also drop the fixed DH anon ones too, leaving them in might have been inadvertent.

-- 
	Viktor.


From paul.dale at oracle.com  Sun Apr 15 23:03:50 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Sun, 15 Apr 2018 16:03:50 -0700 (PDT)
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <CAHEJ-S5Tnh5uW3PZ-gHaSEMzN3_sSaNjndfxFc+D0yojR2m92g@mail.gmail.com>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <20180415.073848.2255386938941879954.levitte@openssl.org>
 <44330644-C5DD-4E81-869E-3B1597207A4E@akamai.com>
 <F6EED802-4C13-40A1-A16A-B40E751A327D@dukhovni.org>
 <CAHEJ-S5Tnh5uW3PZ-gHaSEMzN3_sSaNjndfxFc+D0yojR2m92g@mail.gmail.com>
Message-ID: <0c640792-ea93-411c-8847-5aa5a9297b58@default>

I?m for ABI compatibility going forward (but not necessarily backwards) and for testing it, preferably in a CI loop.

?

I know I?m late to the discussion but it has been enlightening and it looks like a good outcome.

?

?

Pauli

-- 

Oracle

Dr Paul Dale | Cryptographer | Network Security & Encryption 

Phone +61 7 3031 7217

Oracle Australia

?

From: Tim Hudson [mailto:tjh at cryptsoft.com] 
Sent: Monday, 16 April 2018 3:13 AM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] The problem of (implicit) relinking and changed behaviour

?

Where we are stating that ABI compatibility is in place we should be testing it.

i.e. the older release binaries should be run against the current release libraries - and that should be put into CI in my view.

?

Going the other direction isn't something I have thought we have ever guaranteed (i.e. downgrading) - but programs that don't use new APIs (i.e. for the ABI) should also work - that is pretty much the definition of an ABI.

If we are unable to provide the forward ABI then we need to change the version number of the release going forward. If weare unable to provide backwards ABI then we need to think about how we are defining things and make that clear.

?

And we need to be clear about what we mean by ABI - I don't think we have written down a clear definition - and then have in CI the tests to match what we are saying we do.

?

When it comes to TLSv1.3 it is highly desirable that an existing 1.1.0 application gets TLSv1.3 without API changes - i.e. ABI provides this. There will be some things where there are problems where assumptions are invalidated - but we should work to minimise those (and I think we have actually done so).

But again we should be testing this in CI - if we want old apps to all get TLSv1.3 for zero effort (other than a shared library upgrade) then we should test that in CI. Hoping it works or assuming it works and "manually" watching for changes that might invalidate that is rather error prone.

?

What Richard is doing really helps add to the information for informed decisions ... the more information we have the better in my view.

?

Tim.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180415/ef8f2abb/attachment-0001.html>

From rsalz at akamai.com  Sun Apr 15 23:44:11 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 15 Apr 2018 23:44:11 +0000
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180415212027.GB54168@kduck.kaduk.org>
References: <20180414.213231.903361400025235343.levitte@openssl.org>
 <ac42d34d-4ad9-3646-19a9-e9e3521d615a@openssl.org>
 <20180415.134929.564430745296199664.levitte@openssl.org>
 <20180415212027.GB54168@kduck.kaduk.org>
Message-ID: <34291E58-91D4-4FE9-8EE6-C08DFC45578A@akamai.com>

   >  That said, I have to wonder
    if doing things like reverting old changes that we don't have CLAs
    for

Just to comment on this one item in your very thoughtful note.  We did discuss things within the OMC, and we decided to do this because we really want to change the license with this release.



From levitte at openssl.org  Mon Apr 16 06:22:59 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 16 Apr 2018 08:22:59 +0200 (CEST)
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <877ep8s738.fsf@fifthhorseman.net>
References: <ac42d34d-4ad9-3646-19a9-e9e3521d615a@openssl.org>
 <20180415.134929.564430745296199664.levitte@openssl.org>
 <877ep8s738.fsf@fifthhorseman.net>
Message-ID: <20180416.082259.902107541528061159.levitte@openssl.org>

In message <877ep8s738.fsf at fifthhorseman.net> on Sun, 15 Apr 2018 10:38:35 -0700, Daniel Kahn Gillmor <dkg at fifthhorseman.net> said:

dkg> Ideally, the semantics of the OpenSSL API for *most* users of the
dkg> library should be roughly "give me the best TLS session you can give".
dkg> There's no breakage in that API if the underlying library suddenly
dkg> starts negotiating TLS 1.3.

I generally agree.

dkg> An application which uses that API and then breaks because it got a
dkg> version of TLS or a ciphersuite that it didn't expect is mis-using the
dkg> API (or, is part of the test suite, which is actually testing the
dkg> internals of the library it was built against and we should expect a
dkg> failure if the library used is changed out from under it).

Generally speaking, I don't necesseraly agree.  If the use of an API
is perfectly valid for the conditions a program was built for, and
then suddenly breaks down because the new kid in town wanna play,
I find it hard to call that mis-use.  I would much rather have libssl
do something along the lines of "oh, you're one of the old guys, let's
use something that works for you".

dkg> I'm all for making a breaking changes in the OpenSSL API to discourage
dkg> use of bad/legacy API.

That calls for a major version change (in OpenSSL versioning, that
would be 1.2.0).  I think we've all come to some kind of agreement
that doing this isn't desirable at this point...

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From matt at openssl.org  Mon Apr 16 10:00:30 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Apr 2018 11:00:30 +0100
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <7C84EC32-0158-47D6-AF22-4C96659EADEB@dukhovni.org>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <20180415.073848.2255386938941879954.levitte@openssl.org>
 <508D88C5-9604-4441-86D6-8CC137E04717@dukhovni.org>
 <AM5PR0701MB265783557331E9B4355D0629E4B10@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <7C84EC32-0158-47D6-AF22-4C96659EADEB@dukhovni.org>
Message-ID: <0a560b9c-b250-d597-b9cc-2ef84b62fbd3@openssl.org>



On 15/04/18 17:18, Viktor Dukhovni wrote:
> 
> 
>> On Apr 15, 2018, at 2:24 AM, Bernd Edlinger <bernd.edlinger at hotmail.de> wrote:
>>
>> One possible example of application failure that I am aware of is #5743:
>> A certificate that is incompatible with TLS1.3 but works with TLS1.2.
>> Admittedly that I did come up with that scenario only because I saw
>> a possible issue per code inspection.
> 
> [ Repeating in part my response to Richar's mesage also in this thread ]
> 
> This is a bug that needs to be fixed, the point format for TLS does not
> have any provenance over X.509.  There's no such thing as a certificate
> not compatible with TLS 1.3 (that is compatible with TLS 1.2).
> 

That's not entirely true. This works:

$ openssl s_server -cert dsacert.pem -key dsakey.pem -cipher ALL:@SECLEVEL=0
$ openssl s_client -no_tls1_3 -cipher ALL at SECLEVEL=0

This doesn't:

$ openssl s_server -cert dsacert.pem -key dsakey.pem -cipher ALL:@SECLEVEL=0
$ openssl s_client -cipher ALL at SECLEVEL=0

139667082474432:error:14201076:SSL routines:tls_choose_sigalg:no
suitable signature algorithm:ssl/t1_lib.c:2484:

We do not allow DSA certs in TLSv1.3.

Matt

From openssl-users at dukhovni.org  Mon Apr 16 14:16:44 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 16 Apr 2018 10:16:44 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <0a560b9c-b250-d597-b9cc-2ef84b62fbd3@openssl.org>
References: <D371758F-1CB0-48E5-8590-48094B2A8EF8@dukhovni.org>
 <20180414.230917.75972276947889430.levitte@openssl.org>
 <C60D8170-70CB-44A7-86BD-9463D1A021C3@akamai.com>
 <20180415.073848.2255386938941879954.levitte@openssl.org>
 <508D88C5-9604-4441-86D6-8CC137E04717@dukhovni.org>
 <AM5PR0701MB265783557331E9B4355D0629E4B10@AM5PR0701MB2657.eurprd07.prod.outlook.com>
 <7C84EC32-0158-47D6-AF22-4C96659EADEB@dukhovni.org>
 <0a560b9c-b250-d597-b9cc-2ef84b62fbd3@openssl.org>
Message-ID: <AFDF924D-79B7-42F2-8900-0873A089900B@dukhovni.org>



> On Apr 16, 2018, at 6:00 AM, Matt Caswell <matt at openssl.org> wrote:
> 
> That's not entirely true. This works:
> 
> $ openssl s_server -cert dsacert.pem -key dsakey.pem -cipher ALL:@SECLEVEL=0
> $ openssl s_client -no_tls1_3 -cipher ALL at SECLEVEL=0
> 
> This doesn't:
> 
> $ openssl s_server -cert dsacert.pem -key dsakey.pem -cipher ALL:@SECLEVEL=0
> $ openssl s_client -cipher ALL at SECLEVEL=0
> 
> 139667082474432:error:14201076:SSL routines:tls_choose_sigalg:no
> suitable signature algorithm:ssl/t1_lib.c:2484:
> 
> We do not allow DSA certs in TLSv1.3.

It is largely time we did not allow them in TLS 1.2 either, nobody
uses them, but perhaps "nobody" == USG?

-- 
	Viktor.


From openssl at openssl.org  Mon Apr 16 15:36:47 2018
From: openssl at openssl.org (OpenSSL)
Date: Mon, 16 Apr 2018 15:36:47 +0000
Subject: [openssl-project] OpenSSL Security Advisory
Message-ID: <20180416153647.GA21276@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


OpenSSL Security Advisory [16 Apr 2018]
========================================

Cache timing vulnerability in RSA Key Generation (CVE-2018-0737)
================================================================

Severity: Low

The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to a
cache timing side channel attack. An attacker with sufficient access to mount
cache timing attacks during the RSA key generation process could recover the
private key.

Due to the low severity of this issue we are not issuing a new release of
OpenSSL 1.1.0 or 1.0.2 at this time. The fix will be included in OpenSSL 1.1.0i
and OpenSSL 1.0.2p when they become available. The fix is also available in
commit 6939eab03 (for 1.1.0) and commit 349a41da1 (for 1.0.2) in the OpenSSL git
repository.

This issue was reported to OpenSSL on 4th April 2018 by Alejandro Cabrera
Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia.
The fix was developed by Billy Brumley.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20180416.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJa1MKgAAoJENnE0m0OYESRKOoIAKmRnj0YtE1y89WnRiCjMk8l
Z7XAsPk6nkEa8dlrEvEsUhS90CFSf9OcYliAlfjD/+RVZXXeK4AHn8/g7HxAdDcK
62biQiHbxICBqnrE6DCe6GrMXEy3MWuefSWnoTyd/x8W1grjdhkrlmIqe68DP0iv
WItmStRVOpx4mQDcrYqw6ZKhhu1Lv007khyAornJP+S6NSlK6brdNQyRNmp3+HO4
irqPi6xQWGcaAtrdpWi8mDnomld75j5m+G98N/gCqaCAIn7Zau+kAAW1+1dO5S4L
tsQ0CifVnRfUTz0cCL51L8G3a3RWYs34AXRZvSRi3q88AiZ1L6FCF2cHZJu1KuE=
=+TYO
-----END PGP SIGNATURE-----

From matt at openssl.org  Mon Apr 16 17:06:33 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Apr 2018 18:06:33 +0100
Subject: [openssl-project] Constant time by default
In-Reply-To: <openssl/openssl/pull/5969@github.com>
References: <openssl/openssl/pull/5969@github.com>
Message-ID: <28c4ef53-28bd-aaab-620d-d24e38de68c8@openssl.org>

I'd like to draw everyone's attention to PR #5969

Given CVE-2018-0737, and the fact that this is far from the first time
this has happened I think we should change the default so that we always
use the constant time implementation unless specifically flagged
otherwise. E.g see these issues:

54f007a (CVE-2018-0737)
8db7946
e913d11
6364475
6364475
3de81a5
47ae05b
033dc8f
3999446 (CVE-2016-2178)

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.

Matt



From rsalz at akamai.com  Mon Apr 16 17:09:30 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 16 Apr 2018 17:09:30 +0000
Subject: [openssl-project] Constant time by default
In-Reply-To: <28c4ef53-28bd-aaab-620d-d24e38de68c8@openssl.org>
References: <openssl/openssl/pull/5969@github.com>
 <28c4ef53-28bd-aaab-620d-d24e38de68c8@openssl.org>
Message-ID: <C5997BD2-B2B3-4921-96CD-505EAB2CB3BE@akamai.com>

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)


From matt at openssl.org  Mon Apr 16 17:47:17 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Apr 2018 18:47:17 +0100
Subject: [openssl-project] Fwd: New Defects reported by Coverity Scan for
	openssl/openssl
In-Reply-To: <5ad3046a8db6e_8032b08291e2f6074477@node1.mail>
References: <5ad3046a8db6e_8032b08291e2f6074477@node1.mail>
Message-ID: <88829e27-2fb1-5b13-cd5d-c297c2192920@openssl.org>

Can anyone enlighten me as to why I can't find half of these defects in
the coverity dashboard? None of the reported defects in the test cases
seem to exist any more (and I'm fairly sure we didn't fix them).
Actually I didn't think we scanned the tests at all, so I'm a little
confused.

Matt



-------- Forwarded Message --------
Subject: New Defects reported by Coverity Scan for openssl/openssl
Date: Sun, 15 Apr 2018 07:51:06 +0000 (UTC)
From: scan-admin at coverity.com
To: matt at openssl.org

Hi,

Please find the latest report on new defect(s) introduced to
openssl/openssl found with Coverity Scan.

5 new defect(s) introduced to openssl/openssl found with Coverity Scan.
4 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 5 of 5 defect(s)


** CID 1434551:  Code maintainability issues  (SIZEOF_MISMATCH)
/test/sslapitest.c: 3831 in create_new_vfile()


________________________________________________________________________________________________________
*** CID 1434551:  Code maintainability issues  (SIZEOF_MISMATCH)
/test/sslapitest.c: 3831 in create_new_vfile()
3825         return ret;
3826     }
3827     3828     static int create_new_vfile(char *userid, char
*password, const char *filename)
3829     {
3830         char *gNid = NULL;
>>>     CID 1434551:  Code maintainability issues  (SIZEOF_MISMATCH)
>>>     Passing argument "56UL /* sizeof (row) * (6 + 1) */" to function "CRYPTO_zalloc" and then casting the return value to "OPENSSL_STRING *" is suspicious.  In this particular case "sizeof (OPENSSL_STRING *)" happens to be equal to "sizeof (OPENSSL_STRING)", but this is not a portable assumption.
3831         OPENSSL_STRING *row = OPENSSL_zalloc(sizeof(row) *
(DB_NUMBER + 1));
3832         TXT_DB *db = NULL;
3833         int ret = 0;
3834         BIO *out = NULL, *dummy = BIO_new_mem_buf("", 0);
3835         size_t i;
3836
** CID 1434550:    (RESOURCE_LEAK)
/crypto/srp/srp_vfy.c: 73 in t_fromb64()
/crypto/srp/srp_vfy.c: 97 in t_fromb64()


________________________________________________________________________________________________________
*** CID 1434550:    (RESOURCE_LEAK)
/crypto/srp/srp_vfy.c: 73 in t_fromb64()
67          *  2 bytes unencoded = 3 bytes encoded
68          *  3 bytes unencoded = 4 bytes encoded
69          *  4 bytes unencoded = 6 bytes encoded
70          *  etc
71          */
72         if (padsize == 3)
>>>     CID 1434550:    (RESOURCE_LEAK)
>>>     Variable "ctx" going out of scope leaks the storage it points to.
73             return -1;
74     75         /* Valid padsize values are now 0, 1 or 2 */
76     77         EVP_DecodeInit(ctx);
78         evp_encode_ctx_set_flags(ctx, EVP_ENCODE_CTX_USE_SRP_ALPHABET);
/crypto/srp/srp_vfy.c: 97 in t_fromb64()
91         EVP_DecodeFinal(ctx, a + outl, &outl2);
92         outl += outl2;
93     94         /* Strip off the leading padding */
95         if (padsize != 0) {
96             if ((int)padsize >= outl)
>>>     CID 1434550:    (RESOURCE_LEAK)
>>>     Variable "ctx" going out of scope leaks the storage it points to.
97                 return -1;
98             /*
99              * If we added 1 byte of padding prior to encoding then
we have 2 bytes
100              * of "real" data which gets spread across 4 encoded
bytes like this:
101              *   (6 bits pad)(2 bits pad | 4 bits data)(6 bits
data)(6 bits data)
102              * So 1 byte of pre-encoding padding results in 1 full
byte of encoded

** CID 1434549:  Error handling issues  (CHECKED_RETURN)
/test/evp_test.c: 1553 in encode_test_run()


________________________________________________________________________________________________________
*** CID 1434549:  Error handling issues  (CHECKED_RETURN)
/test/evp_test.c: 1553 in encode_test_run()
1547             if (!TEST_ptr(encode_ctx = EVP_ENCODE_CTX_new())
1548                     || !TEST_ptr(encode_out =
1549
OPENSSL_malloc(EVP_ENCODE_LENGTH(expected->input_len))))
1550                 goto err;
1551     1552             EVP_EncodeInit(encode_ctx);
>>>     CID 1434549:  Error handling issues  (CHECKED_RETURN)
>>>     Calling "EVP_EncodeUpdate" without checking return value (as is done elsewhere 4 out of 5 times).
1553             EVP_EncodeUpdate(encode_ctx, encode_out, &chunk_len,
1554                              expected->input, expected->input_len);
1555             output_len = chunk_len;
1556     1557             EVP_EncodeFinal(encode_ctx, encode_out +
chunk_len, &chunk_len);
1558             output_len += chunk_len;

** CID 1434548:  Error handling issues  (CHECKED_RETURN)
/test/drbgtest.c: 800 in run_multi_thread_test()


________________________________________________________________________________________________________
*** CID 1434548:  Error handling issues  (CHECKED_RETURN)
/test/drbgtest.c: 800 in run_multi_thread_test()
794         private = RAND_DRBG_get0_private();
795         RAND_DRBG_set_reseed_time_interval(public, 1);
796         RAND_DRBG_set_reseed_time_interval(private, 1);
797     798         do {
799             RAND_bytes(buf, sizeof(buf));
>>>     CID 1434548:  Error handling issues  (CHECKED_RETURN)
>>>     Calling "RAND_priv_bytes" without checking return value (as is done elsewhere 16 out of 18 times).
800             RAND_priv_bytes(buf, sizeof(buf));
801         }
802         while(time(NULL) - start < 5);
803     }
804     805     # if defined(OPENSSL_SYS_WINDOWS)

** CID 1420020:  Error handling issues  (CHECKED_RETURN)
/crypto/rand/drbg_lib.c: 872 in drbg_setup()


________________________________________________________________________________________________________
*** CID 1420020:  Error handling issues  (CHECKED_RETURN)
/crypto/rand/drbg_lib.c: 872 in drbg_setup()
866         /*
867          * Ignore instantiation error so support just-in-time
instantiation.
868          *
869          * The state of the drbg will be checked in
RAND_DRBG_generate() and
870          * an automatic recovery is attempted.
871          */
>>>     CID 1420020:  Error handling issues  (CHECKED_RETURN)
>>>     Calling "RAND_DRBG_instantiate" without checking return value (as is done elsewhere 12 out of 15 times).
872         RAND_DRBG_instantiate(drbg,
873                               (const unsigned char *) ossl_pers_string,
874                               sizeof(ossl_pers_string) - 1);
875         return drbg;
876     877     err:


________________________________________________________________________________________________________
To view the defects in Coverity Scan visit,
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRakUl6QyjujEohY7rPpoYUE4H-2Fm-2BeoDOl8jw7bf4Z78hw-3D-3D_jrN6Mkpcg292t2HUi6j2dOVH2S6heGK5ZBOjbNfqPH352dQ5xl0pmJRAY1ip5LVafcjoehH47QcmnVMVCHS75-2Ffv-2B94fTDmxchItGwcKtjA-2BglyL1TseBRnNUMhRjRykmFEkv8zDqkoLWEz-2BDl-2BBvfjUa-2BIbV1PG73z2fX3eGyKo-2FakWQ9j6MYAOjEEj-2BsmLXZo1rKLb3gaoucm4fJc-2FHQ-3D-3D

  To manage Coverity Scan email notifications for "matt at openssl.org",
click
https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4XSSb7qvu4FGGtzK9WuNy1Lsp-2BrdaVsnhVj6c7TxZVrqIhf5NIcqyR2fY4BU0Ynocxg3sT5sVvEU3dzDXH7yZ8-2B3X-2BdloVx0HAWCGstNd5pk-3D_jrN6Mkpcg292t2HUi6j2dOVH2S6heGK5ZBOjbNfqPH352dQ5xl0pmJRAY1ip5LVaVaWmJmxMmT9A4rVYbckAU8jCnfVpDJqTWh7nUQks-2B649caFtImdjTQSntJYbRcLOQVS7nByix-2FIyHIS5piFXlYFU2c-2B3EVLKT1nlqloFoR24XYbeGsz9a0RKTdAUfY5uTegMqMm2s0pXbOLbDll9hw-3D-3D


From davidben at google.com  Mon Apr 16 17:57:33 2018
From: davidben at google.com (David Benjamin)
Date: Mon, 16 Apr 2018 17:57:33 +0000
Subject: [openssl-project] Constant time by default
In-Reply-To: <C5997BD2-B2B3-4921-96CD-505EAB2CB3BE@akamai.com>
References: <openssl/openssl/pull/5969@github.com>
 <28c4ef53-28bd-aaab-620d-d24e38de68c8@openssl.org>
 <C5997BD2-B2B3-4921-96CD-505EAB2CB3BE@akamai.com>
Message-ID: <CAF8qwaASAB-RhKO8xjSUp1RzizP12xEiao2-wPTXXekxA=Nm7A@mail.gmail.com>

I was actually going to file a ticket somewhere and never got around to
it...

In BoringSSL, we've instead gone the route of removing BN_FLG_CONSTTIME
altogether. Rather call sites which need a particular function call that
function directly. I think this is much less error-prone (as the various
problems here show). Of course, OpenSSL can't fully get rid of
BN_FLG_CONSTTIME until 1.2.0, but it could arrange for the library to no
longer rely on it internally.

In a crypto library, "modular exponentiation" is not a complete API
contract. Rather, you need contracts like "modular exponentiation with
secret fully-reduced base and public exponent" or "modular exponentiation
with secret fully-reduced base and secret exponent publicly bounded by
such-and-such". Cast in that light, I think it becomes much clearer that
they should be separate functions. You could even imagine embedding secrecy
into the type (either for safety or to take advantage of some future
compiler annotations), in which case separate functions is necessary.

This also aligns with the guidelines here:
https://github.com/HACS-workshop/spectre-mitigations/blob/master/crypto_guidelines.md#2-avoid-indirect-branches-in-constant-time-code

On Mon, Apr 16, 2018 at 1:09 PM Salz, Rich <rsalz at akamai.com> wrote:

> 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)
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180416/ea373079/attachment.html>

From Matthias.St.Pierre at ncp-e.com  Tue Apr 17 05:06:35 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 17 Apr 2018 07:06:35 +0200
Subject: [openssl-project] Fwd: New Defects reported by Coverity Scan
 for openssl/openssl
In-Reply-To: <88829e27-2fb1-5b13-cd5d-c297c2192920@openssl.org>
References: <5ad3046a8db6e_8032b08291e2f6074477@node1.mail>
 <88829e27-2fb1-5b13-cd5d-c297c2192920@openssl.org>
Message-ID: <0c94b826-8f6c-fa67-1348-f38175378e00@ncp-e.com>

Matt,

I wasn't aware that I can register for coverity reports (which I just
did). If no one else has done it yet, I can look into the three drbg
issues mentioned in your mail.

Matthias

BTW: isn't beta release 3 (pre5) due today? There was no announcement of
a code freeze yet.

Am 16.04.2018 um 19:47 schrieb Matt Caswell:
> Can anyone enlighten me as to why I can't find half of these defects in
> the coverity dashboard? None of the reported defects in the test cases
> seem to exist any more (and I'm fairly sure we didn't fix them).
> Actually I didn't think we scanned the tests at all, so I'm a little
> confused.
>
> Matt
>


From levitte at openssl.org  Tue Apr 17 07:06:58 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 17 Apr 2018 09:06:58 +0200 (CEST)
Subject: [openssl-project] Release of OpenSSL beta release 3 (pre5) happens
Message-ID: <20180417.090658.376062180445914278.levitte@openssl.org>

Hi,

just a reminder that we're scheduled to release openssl-1.1.1-pre5
today.

I'll do the release this time.

If someone could freeze the repo for me, I'd be grateful:

    ssh openssl-git at git.openssl.org freeze openssl levitte

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From matt at openssl.org  Tue Apr 17 08:47:10 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 17 Apr 2018 09:47:10 +0100
Subject: [openssl-project] Fwd: New Defects reported by Coverity Scan
 for openssl/openssl
In-Reply-To: <0c94b826-8f6c-fa67-1348-f38175378e00@ncp-e.com>
References: <5ad3046a8db6e_8032b08291e2f6074477@node1.mail>
 <88829e27-2fb1-5b13-cd5d-c297c2192920@openssl.org>
 <0c94b826-8f6c-fa67-1348-f38175378e00@ncp-e.com>
Message-ID: <42ebbeb9-2eab-afc2-3d1a-36aaf45707b2@openssl.org>



On 17/04/18 06:06, Dr. Matthias St. Pierre wrote:
> Matt,
> 
> I wasn't aware that I can register for coverity reports (which I just
> did). If no one else has done it yet, I can look into the three drbg
> issues mentioned in your mail.


Great! Thanks

Matt

> 
> Matthias
> 
> BTW: isn't beta release 3 (pre5) due today? There was no announcement of
> a code freeze yet.
> 
> Am 16.04.2018 um 19:47 schrieb Matt Caswell:
>> Can anyone enlighten me as to why I can't find half of these defects in
>> the coverity dashboard? None of the reported defects in the test cases
>> seem to exist any more (and I'm fairly sure we didn't fix them).
>> Actually I didn't think we scanned the tests at all, so I'm a little
>> confused.
>>
>> Matt
>>
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From kurt at roeckx.be  Tue Apr 17 12:39:02 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 17 Apr 2018 14:39:02 +0200
Subject: [openssl-project] Constant time by default
In-Reply-To: <CAF8qwaASAB-RhKO8xjSUp1RzizP12xEiao2-wPTXXekxA=Nm7A@mail.gmail.com>
References: <openssl/openssl/pull/5969@github.com>
 <28c4ef53-28bd-aaab-620d-d24e38de68c8@openssl.org>
 <C5997BD2-B2B3-4921-96CD-505EAB2CB3BE@akamai.com>
 <CAF8qwaASAB-RhKO8xjSUp1RzizP12xEiao2-wPTXXekxA=Nm7A@mail.gmail.com>
Message-ID: <20180417123901.GA3660@roeckx.be>

On Mon, Apr 16, 2018 at 05:57:33PM +0000, David Benjamin wrote:
> This also aligns with the guidelines here:
> https://github.com/HACS-workshop/spectre-mitigations/blob/master/crypto_guidelines.md#2-avoid-indirect-branches-in-constant-time-code

I think you actually meant #1 instead of #2

But when reading #2 I think about how for instance we select the
assembler versions, like use AESNI or not.


Kurt


From kurt at roeckx.be  Tue Apr 17 13:10:19 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 17 Apr 2018 15:10:19 +0200
Subject: [openssl-project] Constant time by default
In-Reply-To: <28c4ef53-28bd-aaab-620d-d24e38de68c8@openssl.org>
References: <openssl/openssl/pull/5969@github.com>
 <28c4ef53-28bd-aaab-620d-d24e38de68c8@openssl.org>
Message-ID: <20180417131018.GB3660@roeckx.be>

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


From openssl at openssl.org  Tue Apr 17 14:04:50 2018
From: openssl at openssl.org (OpenSSL)
Date: Tue, 17 Apr 2018 14:04:50 +0000
Subject: [openssl-project] OpenSSL verssion 1.1.1 pre release 5 published
Message-ID: <20180417140450.GA15737@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


   OpenSSL version 1.1.1 pre release 5 (beta)
   ===========================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 5 has now
   been made available. For details of changes and known issues see the
   release notes at:

        https://www.openssl.org/news/openssl-1.1.1-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The beta release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.1-pre5.tar.gz
      Size: 8288689
      SHA1 checksum: 8b479a8c555a9eba57b6003e4bd7200dff9535ee
      SHA256 checksum: 0e5ff2f216cea5fa89af6dcd429c3c142acd7c786b0c4868a039689a2641cf3d

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.1-pre5.tar.gz
    openssl sha256 openssl-1.1.1-pre5.tar.gz

   Please download and check this beta release as soon as possible.
   To report a bug, open an issue on GitHub:

    https://github.com/openssl/openssl/issues

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAlrV93QACgkQ1enkP335
7owHBBAArOo3ChdJyOVRNN9wXPgRJtDTTv22yqadmcgpEiwh5AMWZUCg9Tl8B0BZ
mMcQruV1J0m5qi4mUgBp87ZhqCcOje7uZubyj6VKEAxlklIzyrfPaJyIUWE7CwQi
6jPrMrF9PVkj24DZ/IUPFk6+fJen9POJddeaCuxUM12faZkRD0XxxTEvyKamgou7
Odb/Zn148SFQKMMSVOgaSr0t/go9gJ3vNRaRzBUhG9ZSaxDcwzCaO5OjjwI4xrEY
XnGT54yWJNIvnSsxddhs7q4AUDEa/jNq+iCduPYVbMfuym+7YYMTlKABfnP5i1D2
gd8Ag+2hJe7rtKB6vYKOnyTKJFoMLhoRfJ12N55fJ9L4yLoy5guZEelE2Ib35YWo
twlgQVPu5YnJpZnF0uZTZmcOJruEcQ7e15B8zyZfUIBtqXXg3tcH3QD3noKUYVmf
s8+EfwebwIoLCy8kriO5bogJRVLQHvu1gehTXQa3edrD7iinZzlhdR7UPl9avlnv
7A0XhEiPEqwEmJUdHx/NGH5bydx/cb+oRgB26YTQyqhNw0meQg4znTui/xz2ARE/
r7PWifGhPPAbq8txuj+d8ipDeoyXS46KgR+sF2ncYMS3iQpAddQtCFIU1whpeRip
wGm9uMu41Ba0H3CmUbmgTNU5kE3RCR00kirPiGQfRtf/pwI5zZY=
=vyz+
-----END PGP SIGNATURE-----

From levitte at openssl.org  Tue Apr 17 14:09:55 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 17 Apr 2018 16:09:55 +0200 (CEST)
Subject: [openssl-project] Release done, repository unfrozen
Message-ID: <20180417.160955.626410161437553777.levitte@openssl.org>

OpenSSL 1.1.1 pre release 5 done!
Repository is now unfrozen.

Thank you Matt for the review!

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Tue Apr 17 18:15:37 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 17 Apr 2018 20:15:37 +0200 (CEST)
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <87d0yxq0m7.fsf@fifthhorseman.net>
References: <877ep8s738.fsf@fifthhorseman.net>
 <20180416.082259.902107541528061159.levitte@openssl.org>
 <87d0yxq0m7.fsf@fifthhorseman.net>
Message-ID: <20180417.201537.1881344724528220390.levitte@openssl.org>

In message <87d0yxq0m7.fsf at fifthhorseman.net> on Tue, 17 Apr 2018 09:05:52 -0700, Daniel Kahn Gillmor <dkg at fifthhorseman.net> said:

dkg> On Mon 2018-04-16 08:22:59 +0200, Richard Levitte wrote:
dkg> > Generally speaking, I don't necesseraly agree.  If the use of an API
dkg> > is perfectly valid for the conditions a program was built for, and
dkg> > then suddenly breaks down because the new kid in town wanna play,
dkg> > I find it hard to call that mis-use.  I would much rather have libssl
dkg> > do something along the lines of "oh, you're one of the old guys, let's
dkg> > use something that works for you".
dkg> 
dkg> But if that's the only API semantics, then there's no way for my project
dkg> that depends on libssl to say "do the best thing you know how to do", so
dkg> that i can get benefits from a simple upgrade.

Depends on what "the best thing you know to do" is.  In my mind,
simply refusing to run as before because the new kid in town didn't
like the environment (for example a cert that's perfectly valid for
TLSv1.2 but invalid for TLSv1.3) it ended up in isn't "the best thing
you know to do".

But I get you, your idea of "the best thing you know to do" is to run
the newest protocol unconditionally unless the user / application says
otherwise, regardless of if it's at all possible given the environment
(like said cert).

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From openssl-users at dukhovni.org  Tue Apr 17 18:32:37 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 17 Apr 2018 14:32:37 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180417.201537.1881344724528220390.levitte@openssl.org>
References: <877ep8s738.fsf@fifthhorseman.net>
 <20180416.082259.902107541528061159.levitte@openssl.org>
 <87d0yxq0m7.fsf@fifthhorseman.net>
 <20180417.201537.1881344724528220390.levitte@openssl.org>
Message-ID: <FE841B85-EC0C-4E5A-9C3C-3703A8B1990F@dukhovni.org>



> On Apr 17, 2018, at 2:15 PM, Richard Levitte <levitte at openssl.org> wrote:
> 
> Depends on what "the best thing you know to do" is.  In my mind,
> simply refusing to run as before because the new kid in town didn't
> like the environment (for example a cert that's perfectly valid for
> TLSv1.2 but invalid for TLSv1.3) it ended up in isn't "the best thing
> you know to do".
> 
> But I get you, your idea of "the best thing you know to do" is to run
> the newest protocol unconditionally unless the user / application says
> otherwise, regardless of if it's at all possible given the environment
> (like said cert).

If there were a non-negligible use of certificates that work with TLS 1.2,
and that (implementation bugs aside) can't work with TLS 1.3, I'd support
your position strongly.  As it stands, I think you're right in principle,
but not yet in practice.  If we find no show-stopper issues, we should
allow TLS 1.3 to happen.

I'm far more concerned about lingering middle-box issues, than about some
edge-case certificates...

-- 
	Viktor.


From openssl-users at dukhovni.org  Tue Apr 17 22:36:52 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 17 Apr 2018 18:36:52 -0400
Subject: [openssl-project] TLS 1.3 and SNI
Message-ID: <933EE9FC-9808-4E18-9074-F9DE61DAC83C@dukhovni.org>


Just wanted to check.  The TLS 1.3 draft lists SNI as mandatory to implement, but is not mandatory to use.  Clients should, but do not have to send SNI, and servers may require SNI, but can just use some default chain instead.

Does OpenSSL's TLS 1.3 support mandate SNI in either the client or server?

-- 
	Viktor.


From matt at openssl.org  Tue Apr 17 22:52:35 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 17 Apr 2018 23:52:35 +0100
Subject: [openssl-project] TLS 1.3 and SNI
In-Reply-To: <933EE9FC-9808-4E18-9074-F9DE61DAC83C@dukhovni.org>
References: <933EE9FC-9808-4E18-9074-F9DE61DAC83C@dukhovni.org>
Message-ID: <0f9c178b-6582-d9e7-6944-4a9932fb5829@openssl.org>



On 17/04/18 23:36, Viktor Dukhovni wrote:
> 
> Just wanted to check.  The TLS 1.3 draft lists SNI as mandatory to implement, but is not mandatory to use.  Clients should, but do not have to send SNI, and servers may require SNI, but can just use some default chain instead.
> 
> Does OpenSSL's TLS 1.3 support mandate SNI in either the client or server?
> 

No. We made changes to s_client to send SNI by default unless you
explicitly request not to. But for applications it's the same story as
always.

Matt

From openssl-users at dukhovni.org  Wed Apr 18 02:19:54 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 17 Apr 2018 22:19:54 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
	(sans SNI)
Message-ID: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>


Applications that have hitherto used TLS <= 1.2 have often not needed to use SNI.  The extension, though useful for virtual-hosting on the Web, was optional.

TLS 1.3 has raised the status of SNI from optional to "mandatory to implement".
What this means that is that implementations must support it, but it stops of
mandating SNI outright.  Clients SHOULD send SNI, when applicable, and servers
MAY require SNI:

  https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.2.2

  -  The "server_name" [RFC6066] and "certificate_authorities"
     extensions are used to guide certificate selection.  As servers
     MAY require the presence of the "server_name" extension, clients
     SHOULD send this extension, when applicable.

  [...]

  Additionally, all implementations MUST support use of the
  "server_name" extension with applications capable of using it.
  Servers MAY require clients to send a valid "server_name" extension.
  Servers requiring this extension SHOULD respond to a ClientHello
  lacking a "server_name" extension by terminating the connection with
  a "missing_extension" alert.

In the world of SMTP, with SMTP server names determined indirectly
and generally insecurely from MX records, it is not generally clear
what name one would use in SNI, and many SMTP clients don't send it
at all.  Some authenticate servers against the nexthop domain (the
envelope recipient domain), others might authenticate the MX host,
or just do unauthenticated opportunistic TLS.  This has worked
acceptably well with TLS <= 1.2

Along comes 1.3, and suddenly some server operators have become
particularly keen on enforcing all sorts of constraints that at
first blush look rather aggressive.  Specifically, the Google
SMTP servers serving millions of domains (including gmail.com),
now only do TLS 1.3 when SNI is presented, and when SNI is missing,
not only negotiate TLS 1.2, but use an unexpected self-signed cert
chain that validating senders will fail to authenticate, and others
may find perplexing in their logs.  (Thanks to Phil Pennock, Bcc'd
for reporting this on the exim-dev list).

When I link posttls-finger with the OpenSSL 1.1.1 library, I see:

  posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25 
    CommonName invalid2.invalid
  posttls-finger: certificate verification failed for
    gmail-smtp-in.l.google.com[173.194.66.26]:25:
    self-signed certificate
  posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25:
    subject_CN=invalid2.invalid, issuer_CN=invalid2.invalid
  posttls-finger: Untrusted TLS connection established to
    gmail-smtp-in.l.google.com[173.194.66.26]:25:
    TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)

The same command with OpenSSL 1.1.0 yields (no CAfile/CApath
so authentication fails where it would typically succeed):

  posttls-finger: certificate verification failed for
    gmail-smtp-in.l.google.com[173.194.66.27]:25:
    untrusted issuer /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
  posttls-finger: gmail-smtp-in.l.google.com[173.194.66.27]:25:
    subject_CN=gmail-smtp-in.l.google.com,
    issuer_CN=Google Internet Authority G3,
  posttls-finger: Untrusted TLS connection established to
    gmail-smtp-in.l.google.com[173.194.66.27]:25:
    TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)

This is a substantial behaviour change from TLS 1.2, and a rather
poor decision on Google's part IMHO, though I'm eager to learn why
this might have been a good idea.

In the mean-time, Richard's objection to automatic TLS 1.3 use
after shared-library upgrade is starting to look more compelling?

Comments?  [ Especially from David Benjamin, if he's in the loop
on the thinking that might have led to the new behaviour ]

-- 
	Viktor.


From levitte at openssl.org  Wed Apr 18 03:24:20 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 18 Apr 2018 05:24:20 +0200 (CEST)
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <FE841B85-EC0C-4E5A-9C3C-3703A8B1990F@dukhovni.org>
References: <87d0yxq0m7.fsf@fifthhorseman.net>
 <20180417.201537.1881344724528220390.levitte@openssl.org>
 <FE841B85-EC0C-4E5A-9C3C-3703A8B1990F@dukhovni.org>
Message-ID: <20180418.052420.874026185832314680.levitte@openssl.org>

In message <FE841B85-EC0C-4E5A-9C3C-3703A8B1990F at dukhovni.org> on Tue, 17 Apr 2018 14:32:37 -0400, Viktor Dukhovni <openssl-users at dukhovni.org> said:

openssl-users> 
openssl-users> 
openssl-users> > On Apr 17, 2018, at 2:15 PM, Richard Levitte <levitte at openssl.org> wrote:
openssl-users> > 
openssl-users> > Depends on what "the best thing you know to do" is.  In my mind,
openssl-users> > simply refusing to run as before because the new kid in town didn't
openssl-users> > like the environment (for example a cert that's perfectly valid for
openssl-users> > TLSv1.2 but invalid for TLSv1.3) it ended up in isn't "the best thing
openssl-users> > you know to do".
openssl-users> > 
openssl-users> > But I get you, your idea of "the best thing you know to do" is to run
openssl-users> > the newest protocol unconditionally unless the user / application says
openssl-users> > otherwise, regardless of if it's at all possible given the environment
openssl-users> > (like said cert).
openssl-users> 
openssl-users> If there were a non-negligible use of certificates that work with TLS 1.2,
openssl-users> and that (implementation bugs aside) can't work with TLS 1.3, I'd support
openssl-users> your position strongly.  As it stands, I think you're right in principle,
openssl-users> but not yet in practice.  If we find no show-stopper issues, we should
openssl-users> allow TLS 1.3 to happen.

The troublesome thing with "but not yet in practice" is that we won't
know before 1.1.1 is finally released and has been deployed in a
larger scale.  In my mind, that's too late.  So my view is much more
black and white, like is it at all possible that there will be
certificates or other "stuff" out there that will have libssl fail
setting up communication because TLSv1.3?  If the answer is yes, I
find it hard to ignore this.

openssl-users> I'm far more concerned about lingering middle-box issues, than about some
openssl-users> edge-case certificates...

There's that too, yeah.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Wed Apr 18 03:27:40 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 18 Apr 2018 03:27:40 +0000
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <20180418.052420.874026185832314680.levitte@openssl.org>
References: <87d0yxq0m7.fsf@fifthhorseman.net>
 <20180417.201537.1881344724528220390.levitte@openssl.org>
 <FE841B85-EC0C-4E5A-9C3C-3703A8B1990F@dukhovni.org>
 <20180418.052420.874026185832314680.levitte@openssl.org>
Message-ID: <BC91A938-96BD-4BB0-94F3-8EE0942DC0FB@akamai.com>

So far, if there's no SNI then we shouldn't do TLS 1.3 (as a client).  That seems easy to code.


From openssl-users at dukhovni.org  Wed Apr 18 03:55:39 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 17 Apr 2018 23:55:39 -0400
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <BC91A938-96BD-4BB0-94F3-8EE0942DC0FB@akamai.com>
References: <87d0yxq0m7.fsf@fifthhorseman.net>
 <20180417.201537.1881344724528220390.levitte@openssl.org>
 <FE841B85-EC0C-4E5A-9C3C-3703A8B1990F@dukhovni.org>
 <20180418.052420.874026185832314680.levitte@openssl.org>
 <BC91A938-96BD-4BB0-94F3-8EE0942DC0FB@akamai.com>
Message-ID: <58D7C246-DFB5-420E-A2DF-611078252717@dukhovni.org>



> On Apr 17, 2018, at 11:27 PM, Salz, Rich <rsalz at akamai.com> wrote:
> 
> So far, if there's no SNI then we shouldn't do TLS 1.3 (as a client).  That seems easy to code.

That might be a sensible work-around, with a bit of care to make sure that the user has not also disabled TLS 1.2 (i.e. try TLS 1.3 without SNI if that's all that is enabled).

Would still like to know what's motivating Google's insistence on SNI...
Sounds like a rather unnecessary downgrade.

-- 
	Viktor.


From rsalz at akamai.com  Wed Apr 18 12:25:48 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 18 Apr 2018 12:25:48 +0000
Subject: [openssl-project] The problem of (implicit) relinking and
 changed behaviour
In-Reply-To: <58D7C246-DFB5-420E-A2DF-611078252717@dukhovni.org>
References: <87d0yxq0m7.fsf@fifthhorseman.net>
 <20180417.201537.1881344724528220390.levitte@openssl.org>
 <FE841B85-EC0C-4E5A-9C3C-3703A8B1990F@dukhovni.org>
 <20180418.052420.874026185832314680.levitte@openssl.org>
 <BC91A938-96BD-4BB0-94F3-8EE0942DC0FB@akamai.com>
 <58D7C246-DFB5-420E-A2DF-611078252717@dukhovni.org>
Message-ID: <643D31A6-07AF-4C39-8196-6500C7C23776@akamai.com>

>    Would still like to know what's motivating Google's insistence on SNI...

The TLS WG is probably the place to ask this.


From appro at openssl.org  Wed Apr 18 14:12:51 2018
From: appro at openssl.org (Andy Polyakov)
Date: Wed, 18 Apr 2018 16:12:51 +0200
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
Message-ID: <ed5cc38e-d65c-32b2-3c6b-95c90bea07eb@openssl.org>

> When I link posttls-finger with the OpenSSL 1.1.1 library, I see:

Just in case for reference, one can reproduce all this with 1.1.1
s_client. Below case is -starttls smtp -noservername. "Fun" part is that
OU for the self-signed certificate reads "No SNI provided; please fix
your client." Another "fun" part is that they don't seem to be concerned
with SNI value, it can be literally whatever.

>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25 
>     CommonName invalid2.invalid
>   posttls-finger: certificate verification failed for
>     gmail-smtp-in.l.google.com[173.194.66.26]:25:
>     self-signed certificate
>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25:
>     subject_CN=invalid2.invalid, issuer_CN=invalid2.invalid
>   posttls-finger: Untrusted TLS connection established to
>     gmail-smtp-in.l.google.com[173.194.66.26]:25:
>     TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)

Below case is -starttls smtp -tls1_2 [with of without servername].

> The same command with OpenSSL 1.1.0 yields (no CAfile/CApath
> so authentication fails where it would typically succeed):
> 
>   posttls-finger: certificate verification failed for
>     gmail-smtp-in.l.google.com[173.194.66.27]:25:
>     untrusted issuer /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.27]:25:
>     subject_CN=gmail-smtp-in.l.google.com,
>     issuer_CN=Google Internet Authority G3,
>   posttls-finger: Untrusted TLS connection established to
>     gmail-smtp-in.l.google.com[173.194.66.27]:25:
>     TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
> 
> This is a substantial behaviour change from TLS 1.2, and a rather
> poor decision on Google's part IMHO, though I'm eager to learn why
> this might have been a good idea.
> 
> In the mean-time, Richard's objection to automatic TLS 1.3 use
> after shared-library upgrade is starting to look more compelling?

Question is what would be users' expectation. If we arrange it so that
application compiled with 1.1.0 simply won't negotiate 1.3, then would
it be reasonable of them to expect that it will start working if they
simply recompile application? I.e. without changing application code!
But in such case it wouldn't actually help for example this case, but
only make things more confusing. I mean you end up with "all I wanted
1.3 and now it doesn't work at all". I'd say that it would be more
appropriate to make user ask "I want 1.3 but don't get it, why? it keeps
working with 1.2 though." With this in mind, wouldn't it be more
appropriate to simply not offer 1.3 capability if application didn't
provide input for SNI?

From openssl-users at dukhovni.org  Wed Apr 18 14:25:27 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 18 Apr 2018 10:25:27 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <ed5cc38e-d65c-32b2-3c6b-95c90bea07eb@openssl.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <ed5cc38e-d65c-32b2-3c6b-95c90bea07eb@openssl.org>
Message-ID: <75195534-A9CE-4B85-834D-4C9D62CBBDFF@dukhovni.org>



> On Apr 18, 2018, at 10:12 AM, Andy Polyakov <appro at openssl.org> wrote:
> 
> With this in mind, wouldn't it be more
> appropriate to simply not offer 1.3 capability if application didn't
> provide input for SNI?

That's what Rich suggested, and it makes sense, but what does not make any sense to me is what Google is doing.  Snatching defeat from the jaws of victory by needlessly forcing clients to downgrade to TLS 1.2.  Is there a justification for this?

-- 
	Viktor.


From appro at openssl.org  Wed Apr 18 14:43:54 2018
From: appro at openssl.org (Andy Polyakov)
Date: Wed, 18 Apr 2018 16:43:54 +0200
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <75195534-A9CE-4B85-834D-4C9D62CBBDFF@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <ed5cc38e-d65c-32b2-3c6b-95c90bea07eb@openssl.org>
 <75195534-A9CE-4B85-834D-4C9D62CBBDFF@dukhovni.org>
Message-ID: <eb21e59f-1685-aaf3-b3fb-29f3afee65ab@openssl.org>

> ... what does not make any sense to me is what Google is doing.  Snatching defeat from the jaws of victory by needlessly forcing clients to downgrade to TLS 1.2.  Is there a justification for this?

It can either be a probe just to see if it's reasonable to demand it, or
establish a precedent that they can refer to saying "it was always like
that, *your* application is broken, not ours." Also note that formally
speaking you can't blame them for demanding it. But you can blame them
for demanding it wrong. I mean they shouldn't try to communicate through
OU of self-signed certificate, but by terminating connection with
missing_extension alert, should they?

From rsalz at akamai.com  Wed Apr 18 15:02:11 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 18 Apr 2018 15:02:11 +0000
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <75195534-A9CE-4B85-834D-4C9D62CBBDFF@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <ed5cc38e-d65c-32b2-3c6b-95c90bea07eb@openssl.org>
 <75195534-A9CE-4B85-834D-4C9D62CBBDFF@dukhovni.org>
Message-ID: <B001BE18-B7D1-4D83-B527-018C9B1D9463@akamai.com>

>    That's what Rich suggested, and it makes sense, but what does not make any sense to me is what Google is doing.  Snatching defeat from the jaws of victory by needlessly forcing clients to downgrade to TLS 1.2.  Is there a justification for this?
  
It's Google's internet, we just use it.  If you have the #1 browser and the #1 website you can force all sorts of things to happen.

Take this up on the TLSWG mailing list.



From openssl-users at dukhovni.org  Wed Apr 18 15:05:05 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 18 Apr 2018 11:05:05 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <eb21e59f-1685-aaf3-b3fb-29f3afee65ab@openssl.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <ed5cc38e-d65c-32b2-3c6b-95c90bea07eb@openssl.org>
 <75195534-A9CE-4B85-834D-4C9D62CBBDFF@dukhovni.org>
 <eb21e59f-1685-aaf3-b3fb-29f3afee65ab@openssl.org>
Message-ID: <4C029FB2-45D6-4718-838B-BC6DAE08EA47@dukhovni.org>



> On Apr 18, 2018, at 10:43 AM, Andy Polyakov <appro at openssl.org> wrote:
> 
> It can either be a probe just to see if it's reasonable to demand it, or
> establish a precedent that they can refer to saying "it was always like
> that, *your* application is broken, not ours." Also note that formally
> speaking you can't blame them for demanding it. But you can blame them
> for demanding it wrong. I mean they shouldn't try to communicate through
> OU of self-signed certificate, but by terminating connection with
> missing_extension alert, should they?

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?

-- 
	Viktor.


From kurt at roeckx.be  Wed Apr 18 17:14:47 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 18 Apr 2018 19:14:47 +0200
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <4C029FB2-45D6-4718-838B-BC6DAE08EA47@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <ed5cc38e-d65c-32b2-3c6b-95c90bea07eb@openssl.org>
 <75195534-A9CE-4B85-834D-4C9D62CBBDFF@dukhovni.org>
 <eb21e59f-1685-aaf3-b3fb-29f3afee65ab@openssl.org>
 <4C029FB2-45D6-4718-838B-BC6DAE08EA47@dukhovni.org>
Message-ID: <20180418171447.GA6885@roeckx.be>

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


From openssl-users at dukhovni.org  Wed Apr 18 17:42:58 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 18 Apr 2018 13:42:58 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <20180418171447.GA6885@roeckx.be>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <ed5cc38e-d65c-32b2-3c6b-95c90bea07eb@openssl.org>
 <75195534-A9CE-4B85-834D-4C9D62CBBDFF@dukhovni.org>
 <eb21e59f-1685-aaf3-b3fb-29f3afee65ab@openssl.org>
 <4C029FB2-45D6-4718-838B-BC6DAE08EA47@dukhovni.org>
 <20180418171447.GA6885@roeckx.be>
Message-ID: <073BCE4C-C1D6-4A66-A1B3-7977D76E9953@dukhovni.org>



> On Apr 18, 2018, at 1:14 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> 
> 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.

Perhaps that's right, even with SNI I get TLS 1.2, but with the right
certificate, whereas without SNI I get the wrong certificate.  It is
not clear what will happen when they actually support TLS 1.3.

-- 
	Viktor.


From davidben at google.com  Wed Apr 18 22:23:52 2018
From: davidben at google.com (David Benjamin)
Date: Wed, 18 Apr 2018 22:23:52 +0000
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
Message-ID: <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>

Google incurs a significant, ongoing cost to support clients that don't
send SNI. Such clients, at least in the HTTP space, are easy to miss in
casual testing (because browsers do send SNI), and require that we ensure
that a given name is covered by the default certificates on any IP address
that could be served for that name.

However, since not sending SNI generally works for Google services, we not
only have a legacy of clients that could send SNI but don't, but a stream
of new clients that ship without noticing the problem. In short, the
problem is not getting any better.

Rather than break existing clients, with TLS 1.3 we are trying a more
incremental approach: if a client is new enough to support TLS 1.3 then
either it should be sending SNI, or we'll give it a dummy certificate. If
the client didn't send SNI because it doesn't have a hostname to verify
against anyway, then the dummy certificate works just as well. If it does
have a hostname to verify against, then it should send that in SNI.

This only affects the choice of certificate, not the protocol version. To
the downgrade question, that is just, as Kurt suggested, the usual
temporary draft version mismatch and unrelated. The certificate behavior is
triggered by supported_versions in the ClientHello, which is why you're
still seeing it on draft mismatch.

That won't solve clients that aren't updating, but it might at least give
us a negative gradient. We expect this experience with SNI is shared with
other large TLS deployments and hope that the ecosystem effects will
therefore be generally valuable.

The above was done with HTTP in mind, but the code also triggers for SMTP
as you have observed. SMTP is complicated by the fact that it's not so
clear which hostname to verify against: ideally one would match the domain
part of the email address, but in practice we know that doesn't work very
well and that, in many cases, one will trust the MX lookup and verify the
MX name instead.

So, if doing certificate verification, we believe that the logic above
applies and that an MTA should be sending an SNI value equal to what name
they will be validating against. (Or, if you'll accept either, pick
one?probably the MX name.)

If the MTA is not validating certificates, then not sending SNI is fine and
the invalid2.invalid certificate works because it's not being validated
anyway.

Having said that, this was intended more for HTTP-based clients. Our Gmail
team are aware of this and may choose not to apply this behaviour to SMTP
clients in the future.

David and AGL

On Tue, Apr 17, 2018 at 10:29 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

>
> Applications that have hitherto used TLS <= 1.2 have often not needed to
> use SNI.  The extension, though useful for virtual-hosting on the Web, was
> optional.
>
> TLS 1.3 has raised the status of SNI from optional to "mandatory to
> implement".
> What this means that is that implementations must support it, but it stops
> of
> mandating SNI outright.  Clients SHOULD send SNI, when applicable, and
> servers
> MAY require SNI:
>
>   https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.2.2
>
>   -  The "server_name" [RFC6066] and "certificate_authorities"
>      extensions are used to guide certificate selection.  As servers
>      MAY require the presence of the "server_name" extension, clients
>      SHOULD send this extension, when applicable.
>
>   [...]
>
>   Additionally, all implementations MUST support use of the
>   "server_name" extension with applications capable of using it.
>   Servers MAY require clients to send a valid "server_name" extension.
>   Servers requiring this extension SHOULD respond to a ClientHello
>   lacking a "server_name" extension by terminating the connection with
>   a "missing_extension" alert.
>
> In the world of SMTP, with SMTP server names determined indirectly
> and generally insecurely from MX records, it is not generally clear
> what name one would use in SNI, and many SMTP clients don't send it
> at all.  Some authenticate servers against the nexthop domain (the
> envelope recipient domain), others might authenticate the MX host,
> or just do unauthenticated opportunistic TLS.  This has worked
> acceptably well with TLS <= 1.2
>
> Along comes 1.3, and suddenly some server operators have become
> particularly keen on enforcing all sorts of constraints that at
> first blush look rather aggressive.  Specifically, the Google
> SMTP servers serving millions of domains (including gmail.com),
> now only do TLS 1.3 when SNI is presented, and when SNI is missing,
> not only negotiate TLS 1.2, but use an unexpected self-signed cert
> chain that validating senders will fail to authenticate, and others
> may find perplexing in their logs.  (Thanks to Phil Pennock, Bcc'd
> for reporting this on the exim-dev list).
>
> When I link posttls-finger with the OpenSSL 1.1.1 library, I see:
>
>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25
>     CommonName invalid2.invalid
>   posttls-finger: certificate verification failed for
>     gmail-smtp-in.l.google.com[173.194.66.26]:25:
>     self-signed certificate
>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.26]:25:
>     subject_CN=invalid2.invalid, issuer_CN=invalid2.invalid
>   posttls-finger: Untrusted TLS connection established to
>     gmail-smtp-in.l.google.com[173.194.66.26]:25:
>     TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
>
> The same command with OpenSSL 1.1.0 yields (no CAfile/CApath
> so authentication fails where it would typically succeed):
>
>   posttls-finger: certificate verification failed for
>     gmail-smtp-in.l.google.com[173.194.66.27]:25:
>     untrusted issuer /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
>   posttls-finger: gmail-smtp-in.l.google.com[173.194.66.27]:25:
>     subject_CN=gmail-smtp-in.l.google.com,
>     issuer_CN=Google Internet Authority G3,
>   posttls-finger: Untrusted TLS connection established to
>     gmail-smtp-in.l.google.com[173.194.66.27]:25:
>     TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
>
> This is a substantial behaviour change from TLS 1.2, and a rather
> poor decision on Google's part IMHO, though I'm eager to learn why
> this might have been a good idea.
>
> In the mean-time, Richard's objection to automatic TLS 1.3 use
> after shared-library upgrade is starting to look more compelling?
>
> Comments?  [ Especially from David Benjamin, if he's in the loop
> on the thinking that might have led to the new behaviour ]
>
> --
>         Viktor.
>
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180418/a61fd969/attachment.html>

From openssl-users at dukhovni.org  Wed Apr 18 23:27:41 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 18 Apr 2018 19:27:41 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
Message-ID: <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>



> On Apr 18, 2018, at 6:23 PM, David Benjamin <davidben at google.com> wrote:
> 
> Rather than break existing clients, with TLS 1.3 we are trying a more incremental approach: if a client is new enough to support TLS 1.3 then either it should be sending SNI, or we'll give it a dummy certificate.

So it sure seems like we can't introduce a transparent transition to TLS 1.3 without taking care to disable TLS 1.3 when SNI is not provided.  

Since OpenSSL won't know whether it is doing SMTP or HTTP, or whatever, it means
that OpenSSL will need to disable TLS 1.3 in the absence of SNI across the board.

Consequently, opportunistic SMTP clients (or those using mandatory TLS, but without
DANE where the SNI value is still a guessing game we did not play) won't get TLS 1.3, until they start to make up some sort of SNI name.

It seems to me that all the incentive that clients need to send SNI is not getting the right certificate if they don't, but deliberately withholding the default certificate and sending self-signed invalid is hugely counter-productive.

IMHO, such strategies just delay TLS 1.3 deployment.  If there's a sensible default cert, please don't punish the client and fail to send it.  This sort of thing does not lead to the desired outcome, it just forces work-arounds (such as not doing TLS 1.3).

-- 
	Viktor.


From levitte at openssl.org  Thu Apr 19 07:58:26 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 19 Apr 2018 09:58:26 +0200 (CEST)
Subject: [openssl-project] Problems with waiting for specific person to merge
Message-ID: <20180419.095826.985358702195220841.levitte@openssl.org>

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 perfectly fine to expect from us who are so called fellows, i.e.
who are payed directly to work on OpenSSL...  but to ask this of
everyone else, when their $DAYJOB may suck them into something
entirely different at any given time?  I think that may be quite
unfair, and is bad for the project.

So I think it's time we address this cultural thing (*), and also
perhaps take a closer look at PRs that have been left hanging for this
reason, and take it upon ourselves to help each other merge when we
notice that it doesn't happen on its own.

Cheers,
Richard

(*) It appears to be deep seated...  there have been times when I knew
I was going to be away, and said that anyone is free to merge a PR I
submitted when it's approved, and it still didn't happen before I was
back and did it myself.
-------------- next part --------------
An embedded message was scrubbed...
From: Richard Levitte <notifications at github.com>
Subject: Re: [openssl/openssl] X509_cmp_time: only return 1, 0, -1. (#4955)
Date: Thu, 19 Apr 2018 07:39:31 +0000 (UTC)
Size: 6176
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180419/0662e62d/attachment-0001.mht>

From Matthias.St.Pierre at ncp-e.com  Thu Apr 19 08:30:03 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Thu, 19 Apr 2018 08:30:03 +0000
Subject: [openssl-project] Problems with waiting for specific person to
 merge
In-Reply-To: <20180419.095826.985358702195220841.levitte@openssl.org>
References: <20180419.095826.985358702195220841.levitte@openssl.org>
Message-ID: <9d1d9c5d9b0c4d54ae72d0759d0daec2@Ex13.ncp.local>

Speaking as one of the committer with $PAYROLL != "OpenSSL", I would like to add two remarks.

 I think the reluctance to merge other committer's  pull requests comes from the thought that it might appear impolite or that one does not want to interfere with the other's business. Personally, I don't have a problemat all if my pull requests are merged by others when I don't have the time to do it myself. When somebody notices that a pull request went stale after approval, I would suggest to ping the owner and give him/her a grace period of at least 24 hours to do it by it him/herself.  After that it is perfectly ok to merge it.

For tickets owned by non-committers, my observation is that it is often not clear who will merge. I for myself follow the habbit of self-assigning a ticket as indication that I intend to do the merge. Sometimes others do it the same way, but it is not a general practice. Maybe we could make this a general pattern?

Matthias


> -----Urspr?ngliche Nachricht-----
> Von: openssl-project <openssl-project-bounces at openssl.org> Im Auftrag von Richard Levitte
> Gesendet: Donnerstag, 19. April 2018 09:58
> An: openssl-project at openssl.org
> Betreff: [openssl-project] Problems with waiting for specific person to merge
> 
> 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 perfectly fine to expect from us who are so called fellows, i.e.
> who are payed directly to work on OpenSSL...  but to ask this of
> everyone else, when their $DAYJOB may suck them into something
> entirely different at any given time?  I think that may be quite
> unfair, and is bad for the project.
> 
> So I think it's time we address this cultural thing (*), and also
> perhaps take a closer look at PRs that have been left hanging for this
> reason, and take it upon ourselves to help each other merge when we
> notice that it doesn't happen on its own.
> 
> Cheers,
> Richard
> 
> (*) It appears to be deep seated...  there have been times when I knew
> I was going to be away, and said that anyone is free to merge a PR I
> submitted when it's approved, and it still didn't happen before I was
> back and did it myself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180419/d080525c/attachment.bin>

From levitte at openssl.org  Thu Apr 19 09:04:33 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 19 Apr 2018 11:04:33 +0200 (CEST)
Subject: [openssl-project] Problems with waiting for specific person to
 merge
In-Reply-To: <9d1d9c5d9b0c4d54ae72d0759d0daec2@Ex13.ncp.local>
References: <20180419.095826.985358702195220841.levitte@openssl.org>
 <9d1d9c5d9b0c4d54ae72d0759d0daec2@Ex13.ncp.local>
Message-ID: <20180419.110433.1961053797237175082.levitte@openssl.org>

In message <9d1d9c5d9b0c4d54ae72d0759d0daec2 at Ex13.ncp.local> on Thu, 19 Apr 2018 08:30:03 +0000, "Dr. Matthias St. Pierre" <Matthias.St.Pierre at ncp-e.com> said:

Matthias.St.Pierre> Speaking as one of the committer with $PAYROLL !=
Matthias.St.Pierre> "OpenSSL", I would like to add two remarks.
Matthias.St.Pierre> 
Matthias.St.Pierre> I think the reluctance to merge other committer's
Matthias.St.Pierre> pull requests comes from the thought that it might
Matthias.St.Pierre> appear impolite or that one does not want to
Matthias.St.Pierre> interfere with the other's business. Personally, I
Matthias.St.Pierre> don't have a problemat all if my pull requests are
Matthias.St.Pierre> merged by others when I don't have the time to do
Matthias.St.Pierre> it myself. When somebody notices that a pull
Matthias.St.Pierre> request went stale after approval, I would suggest
Matthias.St.Pierre> to ping the owner and give him/her a grace period
Matthias.St.Pierre> of at least 24 hours to do it by it him/herself.
Matthias.St.Pierre> After that it is perfectly ok to merge it.

Yeah, I get that point, and you're right, there should be an attempt
at a polite exchange first.  In my defence, I had a quick chat with
Emilia a couple of weeks ago, and it became clear that she has a busy
period for the moment.

Matthias.St.Pierre> For tickets owned by non-committers, my
Matthias.St.Pierre> observation is that it is often not clear who will
Matthias.St.Pierre> merge. I for myself follow the habbit of
Matthias.St.Pierre> self-assigning a ticket as indication that I
Matthias.St.Pierre> intend to do the merge. Sometimes others do it the
Matthias.St.Pierre> same way, but it is not a general practice. Maybe
Matthias.St.Pierre> we could make this a general pattern?

This has actually varied a bit.  What I've observed is that the first
to approve is oftentimes the one that merges, unless something else is
said (there have been some PRs where people have asked each other).
Self assigning is a good habit...  unless you have my tendencies, to
*ahem* forget that you've self assigned something.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Thu Apr 19 12:57:39 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 19 Apr 2018 12:57:39 +0000
Subject: [openssl-project] Problems with waiting for specific person to
 merge
In-Reply-To: <20180419.110433.1961053797237175082.levitte@openssl.org>
References: <20180419.095826.985358702195220841.levitte@openssl.org>
 <9d1d9c5d9b0c4d54ae72d0759d0daec2@Ex13.ncp.local>
 <20180419.110433.1961053797237175082.levitte@openssl.org>
Message-ID: <DA9463B3-8A66-4622-9FD4-A150B36B2FFE@akamai.com>


>    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.


From levitte at openssl.org  Thu Apr 19 13:31:39 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 19 Apr 2018 15:31:39 +0200 (CEST)
Subject: [openssl-project] Problems with waiting for specific person to
 merge
In-Reply-To: <DA9463B3-8A66-4622-9FD4-A150B36B2FFE@akamai.com>
References: <9d1d9c5d9b0c4d54ae72d0759d0daec2@Ex13.ncp.local>
 <20180419.110433.1961053797237175082.levitte@openssl.org>
 <DA9463B3-8A66-4622-9FD4-A150B36B2FFE@akamai.com>
Message-ID: <20180419.153139.1554300889019335412.levitte@openssl.org>

In message <DA9463B3-8A66-4622-9FD4-A150B36B2FFE at akamai.com> on Thu, 19 Apr 2018 12:57:39 +0000, "Salz, Rich" <rsalz at akamai.com> said:

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

Thanks...  Now to remember to go there ;-) (I usually start from the
notifications page and relatively seldom go to the PR list...  it's a
habit I probably should change)

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/


From kurt at roeckx.be  Thu Apr 19 15:04:06 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 19 Apr 2018 17:04:06 +0200
Subject: [openssl-project] Problems with waiting for specific person to
 merge
In-Reply-To: <20180419.095826.985358702195220841.levitte@openssl.org>
References: <20180419.095826.985358702195220841.levitte@openssl.org>
Message-ID: <20180419150406.GA14184@roeckx.be>

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


From davidben at google.com  Thu Apr 19 17:31:12 2018
From: davidben at google.com (David Benjamin)
Date: Thu, 19 Apr 2018 17:31:12 +0000
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
Message-ID: <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>

On Wed, Apr 18, 2018 at 7:27 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

>
>
> > On Apr 18, 2018, at 6:23 PM, David Benjamin <davidben at google.com> wrote:
> >
> > Rather than break existing clients, with TLS 1.3 we are trying a more
> incremental approach: if a client is new enough to support TLS 1.3 then
> either it should be sending SNI, or we'll give it a dummy certificate.
>
> So it sure seems like we can't introduce a transparent transition to TLS
> 1.3 without taking care to disable TLS 1.3 when SNI is not provided.
>

I think the TLS 1.3 transition concerns are orthogonal to SNI and this
particular server behavior. At the end of the day, TLS 1.3 does not behave
the same as TLS 1.2 and intentionally has many ratcheting changes.

Consider a caller using a PKCS#1-only ENGINE-backed private key. PKCS#1
does not work in TLS 1.3, only PSS. Consider a caller which calls
SSL_renegotiate. I see that function just fails in TLS 1.3 in OpenSSL right
now. A client which expects the session to be available immediately after
the handshake will also break. Or someone who listens to the message
callback. Or someone who only installed CBC-mode ciphers in initialization.
Or just someone who calls SSL_version and checks that it is TLS1_2_VERSION.

Ultimately, improving TLS in TLS 1.3 means that, although it is a drop-in
upgrade for most scenarios, TLS 1.3 has different deployment considerations
at implementation-dependent corner cases.

OpenSSL is ABI-stable and expects to be updated underneath the calling
application. This means most behavior changes?certainly major protocol
revisions!?are risky. At the same time, it is desirable to have TLS 1.3
enabled for most consumers. This is the usual dilemma: stability for the
uncommon case impedes progress for the common case.

I might suggest conditioning it on the compile-time version of OpenSSL
headers. This is a common transition strategy for systems working through
ABI constraints. (In some systems, this is implemented as some target SDK
version.)

Separately, on the particular SNI incarnation of this general issue:


> Since OpenSSL won't know whether it is doing SMTP or HTTP, or whatever, it
> means
> that OpenSSL will need to disable TLS 1.3 in the absence of SNI across the
> board.
>
> Consequently, opportunistic SMTP clients (or those using mandatory TLS,
> but without
> DANE where the SNI value is still a guessing game we did not play) won't
> get TLS 1.3, until they start to make up some sort of SNI name.
>

I'm not sure I follow this. Why is the SNI value a guessing game? The
client that does not verify the certificate does not care what certificate
it gets. (This is why we still send something, rather than close the
connection.) The client that does verify a certificate, whether or not
failures are fatal, does not need to guess: use the name that is being
verified.

(The DANE case is not very relevant to how Google's servers currently
behave because they do not use DANE.)


> It seems to me that all the incentive that clients need to send SNI is not
> getting the right certificate if they don't, but deliberately withholding
> the default certificate and sending self-signed invalid is hugely
> counter-productive.
>
> IMHO, such strategies just delay TLS 1.3 deployment.  If there's a
> sensible default cert, please don't punish the client and fail to send it.
> This sort of thing does not lead to the desired outcome, it just forces
> work-arounds (such as not doing TLS 1.3).
>

Indeed, the goal is so that clients do not get the right certificate if
they do not send SNI. Sending the default certificate does not achieve
this. The current ecosystem does not reliably send SNI. Without incentives,
it will remain that way. One must arrange for new entrants to behave, so
that someday one can rely on the ecosystem to behave overall. TLS 1.3 is
the ratchet to implement that.

Alternatively, replace sending SNI with supporting RSA-PSS, and the
motivation for requiring RSA-PSS in TLS 1.3 drops out.

Or consider OpenSSL?s default TLS version. Existing OpenSSL consumers are
not reliably TLS-1.3-compatible, so the default cannot be switched. But if
one does not switch the default, new consumers will not enable TLS 1.3, and
will remain TLS-1.3-incompatible. Thus the proposal to use the compile-time
version as ratchet.

Hopefully that helps clarify the reasoning a bit here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20180419/53677f06/attachment-0001.html>

From matt at openssl.org  Thu Apr 19 17:48:35 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 19 Apr 2018 18:48:35 +0100
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
Message-ID: <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>



On 19/04/18 18:31, David Benjamin wrote:
> I might suggest conditioning it on the compile-time version of OpenSSL
> headers. This is a common transition strategy for systems working
> through ABI constraints. (In some systems, this is implemented as some
> target SDK version.)

This is exactly what Richard proposed in this PR:

https://github.com/openssl/openssl/pull/5945

Matt

From openssl-users at dukhovni.org  Thu Apr 19 17:49:25 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 19 Apr 2018 13:49:25 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
Message-ID: <19E6E5F2-C065-4DDC-A7A8-BC4C79CA2007@dukhovni.org>



> On Apr 19, 2018, at 1:31 PM, David Benjamin <davidben at google.com> wrote:
> 
> Consequently, opportunistic SMTP clients (or those using mandatory TLS, but without
> DANE where the SNI value is still a guessing game we did not play) won't get TLS 1.3, until they start to make up some sort of SNI name.
> 
> I'm not sure I follow this. Why is the SNI value a guessing game? The client that does not verify the certificate does not care what certificate it gets. (This is why we still send something, rather than close the connection.) The client that does verify a certificate, whether or not failures are fatal, does not need to guess: use the name that is being verified.

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...

-- 
	Viktor.


From openssl-users at dukhovni.org  Thu Apr 19 18:02:53 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 19 Apr 2018 14:02:53 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <19E6E5F2-C065-4DDC-A7A8-BC4C79CA2007@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <19E6E5F2-C065-4DDC-A7A8-BC4C79CA2007@dukhovni.org>
Message-ID: <66FBDED0-86D3-469F-A314-84929B327F5E@dukhovni.org>



> On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni <openssl-users at dukhovni.org> 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.

And just recompiling against OpenSSL 1.1.1 headers should not suddenly change behaviour.
On the server side there needs to be some recognition of application context, with HTTP servers requiring SNI (where appropriate), but SMTP and other similar applications not doing so.

I'd like to use TLS 1.3 in SMTP, even by default on a recompile or run-time relink with no code changes to explicitly enable TLS 1.3.  But if servers are going to put up unnecessary roadblocks, TLS 1.3 is not going to get much traction.

Please reconsider this particular ratchet (for at least SMTP).  It *is* counter-productive.

Not sure what OpenSSL should do at this point... :-(

-- 
	Viktor.


From openssl-users at dukhovni.org  Thu Apr 19 18:37:38 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 19 Apr 2018 14:37:38 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
Message-ID: <4E893382-4177-4964-BC98-A9EC4ED8A0D9@dukhovni.org>



> On Apr 19, 2018, at 1:31 PM, David Benjamin <davidben at google.com> wrote:
> 
> Consider a caller using a PKCS#1-only ENGINE-backed private key. PKCS#1 does not work in TLS 1.3, only PSS.

That's a local matter, and easy to resolve locally.

> Consider a caller which calls SSL_renegotiate.

Ditto.  And sufficiently uncommon to not worry about.

> A client which expects the session to be available immediately after the handshake will also break.

Sessions are not always offered by the server, clients already have to deal with this.

> Or someone who listens to the message callback.

Not worth worrying about.

> Or someone who only installed CBC-mode ciphers in initialization.

Not a problem, OpenSSL 1.1.1 has separate cipher controls for TLS 1.3

> Or just someone who calls SSL_version and checks that it is TLS1_2_VERSION.

They can set the max version. ...

The above are local edge cases.  The SNI interoperability trap is random damage imposed by apparently capricious remote servers.  I plead you reconsider this *particular* additional hoop for TLS 1.3 clients to jump through, just do whatever you did with TLS 1.2.  If TLS 1.2 failed with SNI, fine do the same with TLS 1.3, if not then return the same chain.

-- 
	Viktor.


From rsalz at akamai.com  Thu Apr 19 18:54:45 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 19 Apr 2018 18:54:45 +0000
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <4E893382-4177-4964-BC98-A9EC4ED8A0D9@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <4E893382-4177-4964-BC98-A9EC4ED8A0D9@dukhovni.org>
Message-ID: <CA51FE6B-6608-4AA8-8000-9F9E6E79C095@akamai.com>

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.
 


From kurt at roeckx.be  Thu Apr 19 19:15:19 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 19 Apr 2018 21:15:19 +0200
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <66FBDED0-86D3-469F-A314-84929B327F5E@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <19E6E5F2-C065-4DDC-A7A8-BC4C79CA2007@dukhovni.org>
 <66FBDED0-86D3-469F-A314-84929B327F5E@dukhovni.org>
Message-ID: <20180419191519.GA18349@roeckx.be>

On Thu, Apr 19, 2018 at 02:02:53PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni <openssl-users at dukhovni.org> 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


From kurt at roeckx.be  Thu Apr 19 19:19:41 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 19 Apr 2018 21:19:41 +0200
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <20180419191519.GA18349@roeckx.be>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <19E6E5F2-C065-4DDC-A7A8-BC4C79CA2007@dukhovni.org>
 <66FBDED0-86D3-469F-A314-84929B327F5E@dukhovni.org>
 <20180419191519.GA18349@roeckx.be>
Message-ID: <20180419191941.GB18349@roeckx.be>

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


From openssl-users at dukhovni.org  Thu Apr 19 19:23:16 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 19 Apr 2018 15:23:16 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <20180419191519.GA18349@roeckx.be>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <19E6E5F2-C065-4DDC-A7A8-BC4C79CA2007@dukhovni.org>
 <66FBDED0-86D3-469F-A314-84929B327F5E@dukhovni.org>
 <20180419191519.GA18349@roeckx.be>
Message-ID: <66B4FCC1-2C06-417C-9167-6A4B9D8293B2@dukhovni.org>



> On Apr 19, 2018, at 3:15 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> 
> 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.

NO.  That's simply not the case, in fact I've contributed significantly
to MTA-STS, and the use-case that fails here is NOT the DANE one (where
SNI is already specified), but rather legacy WebPKI auth for SMTP.

Please don't jump to conclusions or impute motives.

-- 
	Viktor.


From openssl-users at dukhovni.org  Thu Apr 19 19:23:42 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 19 Apr 2018 15:23:42 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <CA51FE6B-6608-4AA8-8000-9F9E6E79C095@akamai.com>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <4E893382-4177-4964-BC98-A9EC4ED8A0D9@dukhovni.org>
 <CA51FE6B-6608-4AA8-8000-9F9E6E79C095@akamai.com>
Message-ID: <26C67BEB-CBA6-43A9-834C-5B9131B0099C@dukhovni.org>



> On Apr 19, 2018, at 2:54 PM, Salz, Rich <rsalz at akamai.com> wrote:
> 
> I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or something like that.

You'll need to retract that.

-- 
	Viktor.


From openssl-users at dukhovni.org  Thu Apr 19 19:45:32 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 19 Apr 2018 15:45:32 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <CA51FE6B-6608-4AA8-8000-9F9E6E79C095@akamai.com>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <4E893382-4177-4964-BC98-A9EC4ED8A0D9@dukhovni.org>
 <CA51FE6B-6608-4AA8-8000-9F9E6E79C095@akamai.com>
Message-ID: <734CFA81-C0FC-4A21-9457-0B2452201542@dukhovni.org>



> On Apr 19, 2018, at 2:54 PM, Salz, Rich <rsalz at akamai.com> wrote:
> 
> David has pointed out valid use-cases.  I think most use-cases will "just work."  We should document the known sharp edges.

I am pointing valid use-cases that David has not taken into account, and conformance ratchets have cost/benefit trade-offs, and are fair game for discussion.  Ad hominem responses are entirely inappropriate, and an apology is due.

David has done lots of good work, but we're all human, and the SNI ratchet is problematic for at least SMTP.  I can legitimately be argued to be a poor tradeoff.

Even in HTTP where the client ought to send SNI, if it does not, but would accept the default certificate (with e.g. TLS 1.2), the rationale for deliberately unusable certificates with TLS 1.3 does not look compelling, especially given the privacy
leaks with SNI.

-- 
-- 
	Viktor.


From rsalz at akamai.com  Thu Apr 19 20:11:27 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 19 Apr 2018 20:11:27 +0000
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <26C67BEB-CBA6-43A9-834C-5B9131B0099C@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <4E893382-4177-4964-BC98-A9EC4ED8A0D9@dukhovni.org>
 <CA51FE6B-6608-4AA8-8000-9F9E6E79C095@akamai.com>
 <26C67BEB-CBA6-43A9-834C-5B9131B0099C@dukhovni.org>
Message-ID: <AAA60D9D-7F26-4DB1-8CB9-AD11BDC61EBF@akamai.com>

Sorry if I offended you.


?On 4/19/18, 3:23 PM, "Viktor Dukhovni" <openssl-users at dukhovni.org> wrote:

    
    
    > On Apr 19, 2018, at 2:54 PM, Salz, Rich <rsalz at akamai.com> wrote:
    > 
    > I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or something like that.
    
    You'll need to retract that.
    
    -- 
    	Viktor.
    
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From rsalz at akamai.com  Thu Apr 19 20:24:35 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 19 Apr 2018 20:24:35 +0000
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <AAA60D9D-7F26-4DB1-8CB9-AD11BDC61EBF@akamai.com>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <4E893382-4177-4964-BC98-A9EC4ED8A0D9@dukhovni.org>
 <CA51FE6B-6608-4AA8-8000-9F9E6E79C095@akamai.com>
 <26C67BEB-CBA6-43A9-834C-5B9131B0099C@dukhovni.org>
 <AAA60D9D-7F26-4DB1-8CB9-AD11BDC61EBF@akamai.com>
Message-ID: <1871EFF6-A73A-4DFD-92A9-6B2E640C3704@akamai.com>

Viktor found my comment offensive, which was not my intent.  I was trying to be light-hearted in commenting on how Viktor dismissed all the issues David raised.

If, in doing so, I went beyond our code of conduct and offended, I am truly truly sorry.
 


From openssl-users at dukhovni.org  Thu Apr 19 20:34:27 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 19 Apr 2018 16:34:27 -0400
Subject: [openssl-project] Potentially bad news on TLS 1.3 compatibility
 (sans SNI)
In-Reply-To: <1871EFF6-A73A-4DFD-92A9-6B2E640C3704@akamai.com>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <4E893382-4177-4964-BC98-A9EC4ED8A0D9@dukhovni.org>
 <CA51FE6B-6608-4AA8-8000-9F9E6E79C095@akamai.com>
 <26C67BEB-CBA6-43A9-834C-5B9131B0099C@dukhovni.org>
 <AAA60D9D-7F26-4DB1-8CB9-AD11BDC61EBF@akamai.com>
 <1871EFF6-A73A-4DFD-92A9-6B2E640C3704@akamai.com>
Message-ID: <1A366E88-3C25-48F1-8D20-2FF7D2F915F3@dukhovni.org>



> On Apr 19, 2018, at 4:24 PM, Salz, Rich <rsalz at akamai.com> wrote:
> 
> Viktor found my comment offensive, which was not my intent.  I was trying to be light-hearted in commenting on how Viktor dismissed all the issues David raised.
> 
> If, in doing so, I went beyond our code of conduct and offended, I am truly truly sorry.

Thanks.  Much appreciated...

Yes, there are other potential obstacles when enabling TLS 1.3 in applications not specifically designed for it.  Some substantial, others less so.

Without going into a length analysis, I think that most of the issues are minor, but authentication failure when an unexpected certificate appears with 1.3 that one would not see with 1.2 seems like a substantially more major hurdle, and one that sure seems avoidable.  I hope it will be looked at more closely and in the not too distant future deployed less broadly (if at all).

-- 
	Viktor.


From openssl-users at dukhovni.org  Thu Apr 19 23:16:04 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 19 Apr 2018 19:16:04 -0400
Subject: [openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)
In-Reply-To: <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
Message-ID: <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>



> On Apr 19, 2018, at 1:48 PM, Matt Caswell <matt at openssl.org> wrote:
> 
>> I might suggest conditioning it on the compile-time version of OpenSSL
>> headers. This is a common transition strategy for systems working
>> through ABI constraints. (In some systems, this is implemented as some
>> target SDK version.)
> 
> This is exactly what Richard proposed in this PR:
> 
> https://github.com/openssl/openssl/pull/5945

So we should get back to what to do about the larger question.

I am skeptical that just the compile-time header version is a
sufficiently good indicator of which applications are prepared
for TLS 1.3.  For most applications integration into a new
release involves recompiling the existing code and running some
tests.

If the tests don't cover interoperability with a sufficiently
diverse set of remote peers, the application will be no more
prepared for TLS 1.3 after compilation against OpenSSL 1.1.1
than it would have been had it been compiled against 1.1.0.

So ideally we (collectively, the OpenSSL, Google, other
TLS toolkits and service providers) will work to reduce
friction so that more applications can use TLS 1.3 without
running into any issues.

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.

  * 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?

  * Something else?

We don't have much time before release, what do we do?

-- 
	Viktor.


From kurt at roeckx.be  Thu Apr 19 23:42:39 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 20 Apr 2018 01:42:39 +0200
Subject: [openssl-project] When to enable TLS 1.3 (was: Google's SNI
 hurdle)
In-Reply-To: <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
 <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
Message-ID: <20180419234238.GA24749@roeckx.be>

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


From levitte at openssl.org  Fri Apr 20 03:37:54 2018
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 20 Apr 2018 05:37:54 +0200 (CEST)
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
References: <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
 <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
Message-ID: <20180420.053754.1068593918255085193.levitte@openssl.org>

In message <C52E12D5-21DB-4FB6-AEED-A873D7364E02 at dukhovni.org> on Thu, 19 Apr 2018 19:16:04 -0400, Viktor Dukhovni <openssl-users at dukhovni.org> said:

openssl-users> But not all the friction can be eliminated, and likely not
openssl-users> all providers can be persuaded to be more accommodating.
openssl-users> Which leaves us with some difficult judgement calls:
openssl-users> 
openssl-users>   * Restrict TLS 1.3 support to just applications compiled
openssl-users>     against 1.1.1?  A weak signal, but likely correlates at
openssl-users>     least somewhat with the application being ready.
openssl-users> 
openssl-users>   * Determine whether the application is likely to be compatible
openssl-users>     at runtime by looking at the provided configuration.  Is SNI
openssl-users>     enabled?  Is the certificate chain weird enough to break with
openssl-users>     TLS 1.3.  Has the application turned off critical algorithms?

Of those two, the second provides for a smoother transition to using
TLSv1.3, all it might take is changing a configuration, getting a
newer certificate with a more compatible chain, changing an engine
module.  Some of those may take some time (even purchasing a new cert,
what do I know?), but still.  If at all possible, the second choice
seems like the better one.

The only reason I can see for the first option is if there are things
that cannot be detected in run-time that would cause the use of older
protocols rather than TLSv1.3.  I suspect a too early call of
SSL_version might be one that's hard to cope with...

openssl-users>   * Do nothing, let the applications adapt or stick with older
openssl-users>     libraries?

I don't see this as acceptable.  Let's remember that 1.1.0 -> 1.1.1 is
a *minor* upgrade, i.e. should be a drop-in backward compatible
replacement.  If that upgrade causes applications to suddenly stop
working because we're force feeding them TLSv1.3, then we've failed
that technical promise.  If I was a user in that scenario, I'd be
furious.

openssl-users>   * Something else?

Making this a *major* upgrade, i.e. 1.2.0.

openssl-users> We don't have much time before release, what do we do?

If we can't resolve this, there is the option of delaying the
release.  The release strategy is clear on this: "This may be amended
at any time as the need arises."
(https://www.openssl.org/policies/releasestrat.html)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kurt at roeckx.be  Fri Apr 20 07:11:39 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 20 Apr 2018 09:11:39 +0200
Subject: [openssl-project] When to enable TLS 1.3 (was: Google's SNI
 hurdle)
In-Reply-To: <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
 <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
Message-ID: <20180420071139.GA32562@roeckx.be>

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


From kurt at roeckx.be  Fri Apr 20 08:11:42 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 20 Apr 2018 10:11:42 +0200
Subject: [openssl-project] When to enable TLS 1.3 (was: Google's SNI
 hurdle)
In-Reply-To: <20180420071139.GA32562@roeckx.be>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
 <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
 <20180420071139.GA32562@roeckx.be>
Message-ID: <20180420081141.GA1347@roeckx.be>

On Fri, Apr 20, 2018 at 09:11:39AM +0200, Kurt Roeckx wrote:
> 
> Maybe we can convert the blog post into a wiki, update it to the
> current status, and point people to that.

I've converted to blog to the wiki:
https://wiki.openssl.org/index.php/TLS1.3

I've made some minor changes, it could use better formatting, and
at least the section about ciphersuites is outdated.


Kurt


From matt at openssl.org  Fri Apr 20 09:16:55 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 20 Apr 2018 10:16:55 +0100
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <20180420081141.GA1347@roeckx.be>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
 <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
 <20180420071139.GA32562@roeckx.be> <20180420081141.GA1347@roeckx.be>
Message-ID: <cf0bd6a2-d31c-677b-696c-efc3171ba9ea@openssl.org>



On 20/04/18 09:11, Kurt Roeckx wrote:
> On Fri, Apr 20, 2018 at 09:11:39AM +0200, Kurt Roeckx wrote:
>>
>> Maybe we can convert the blog post into a wiki, update it to the
>> current status, and point people to that.
> 
> I've converted to blog to the wiki:
> https://wiki.openssl.org/index.php/TLS1.3
> 
> I've made some minor changes, it could use better formatting, and
> at least the section about ciphersuites is outdated.

I have updated the ciphersuites section and fixed the man page links, as
well as a few other content tweaks here and there.

Matt


From levitte at openssl.org  Fri Apr 20 11:57:54 2018
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 20 Apr 2018 13:57:54 +0200 (CEST)
Subject: [openssl-project] Absence now until Tuesday
Message-ID: <20180420.135754.1230369231070429832.levitte@openssl.org>

I will be pretty much absent starting now and until tuesday.  Monday
and Tuesday, I'm attending this event:
https://www.eventbrite.com/e/hp-connect-sweden-vms-sig-annual-meeting-tickets-42639545027

I might be responding to email sporadically.  Don't wait up ;-)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Sat Apr 21 12:22:48 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 21 Apr 2018 12:22:48 +0000
Subject: [openssl-project] FW: [Curdle] I-D Action:
	draft-ietf-curdle-pkix-09.txt
In-Reply-To: <152425941070.27142.12037456561613339150@ietfa.amsl.com>
References: <152425941070.27142.12037456561613339150@ietfa.amsl.com>
Message-ID: <E2483EB8-7106-4F80-8045-25C3A0310CD2@akamai.com>

Anyone up for a doing a PR that adds these to objects.txt?

?On 4/20/18, 5:23 PM, "internet-drafts at ietf.org" <internet-drafts at ietf.org> wrote:

    
    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the CURves, Deprecating and a Little more Encryption WG of the IETF.
    
            Title           : Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure
            Authors         : Simon Josefsson
                              Jim Schaad
    	Filename        : draft-ietf-curdle-pkix-09.txt
    	Pages           : 18
    	Date            : 2018-04-20
    
    Abstract:
       This document specifies algorithm identifiers and ASN.1 encoding
       formats for Elliptic Curve constructs using the curve25519 and
       curve448 curves.  The signature algorithms covered are Ed25519 and
       Ed448.  The key agreement algorithm covered are X25519 and X448.  The
       encoding for Public Key, Private Key and EdDSA digital signature
       structures is provided.
    
    
    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
    
    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-curdle-pkix-09
    https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-09
    
    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-09
    
    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/
    
    _______________________________________________
    Curdle mailing list
    Curdle at ietf.org
    https://www.ietf.org/mailman/listinfo/curdle
    


From kurt at roeckx.be  Sat Apr 21 15:19:31 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 21 Apr 2018 17:19:31 +0200
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <cf0bd6a2-d31c-677b-696c-efc3171ba9ea@openssl.org>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
 <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
 <20180420071139.GA32562@roeckx.be>
 <20180420081141.GA1347@roeckx.be>
 <cf0bd6a2-d31c-677b-696c-efc3171ba9ea@openssl.org>
Message-ID: <20180421151931.GA19066@roeckx.be>

On Fri, Apr 20, 2018 at 10:16:55AM +0100, Matt Caswell wrote:
> On 20/04/18 09:11, Kurt Roeckx wrote:
> > On Fri, Apr 20, 2018 at 09:11:39AM +0200, Kurt Roeckx wrote:
> >>
> >> Maybe we can convert the blog post into a wiki, update it to the
> >> current status, and point people to that.
> > 
> > I've converted to blog to the wiki:
> > https://wiki.openssl.org/index.php/TLS1.3
> > 
> > I've made some minor changes, it could use better formatting, and
> > at least the section about ciphersuites is outdated.
> 
> I have updated the ciphersuites section and fixed the man page links, as
> well as a few other content tweaks here and there.

Thanks.

So should we send out some call for testing? Does someone want to
write a draft message?


Kurt


From kurt at roeckx.be  Sat Apr 21 18:42:02 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 21 Apr 2018 20:42:02 +0200
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <20180421151931.GA19066@roeckx.be>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
 <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
 <20180420071139.GA32562@roeckx.be>
 <20180420081141.GA1347@roeckx.be>
 <cf0bd6a2-d31c-677b-696c-efc3171ba9ea@openssl.org>
 <20180421151931.GA19066@roeckx.be>
Message-ID: <20180421184201.GA3191@roeckx.be>

On Sat, Apr 21, 2018 at 05:19:31PM +0200, Kurt Roeckx wrote:
> On Fri, Apr 20, 2018 at 10:16:55AM +0100, Matt Caswell wrote:
> > On 20/04/18 09:11, Kurt Roeckx wrote:
> > > On Fri, Apr 20, 2018 at 09:11:39AM +0200, Kurt Roeckx wrote:
> > >>
> > >> Maybe we can convert the blog post into a wiki, update it to the
> > >> current status, and point people to that.
> > > 
> > > I've converted to blog to the wiki:
> > > https://wiki.openssl.org/index.php/TLS1.3
> > > 
> > > I've made some minor changes, it could use better formatting, and
> > > at least the section about ciphersuites is outdated.
> > 
> > I have updated the ciphersuites section and fixed the man page links, as
> > well as a few other content tweaks here and there.
> 
> Thanks.
> 
> So should we send out some call for testing? Does someone want to
> write a draft message?

Here is some attempt:

The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
1.3 brings a lot of changes that might cause incompatibility. For
an overview see https://wiki.openssl.org/index.php/TLS1.3

We are considering if we should enable TLS 1.3 by default or not,
or when it should be enabled. For that, we would like to know how
applications behave with the current version.

When testing this, it's important that both sides of the
connection support the same TLS 1.3 draft version. OpenSSL
currently implements draft 26. We would like to see tests
for OpenSSL acting as client and server.

https://github.com/tlswg/tls13-spec/wiki/Implementations lists
other TLS 1.3 implementations and the draft they currently
support. Note that the versions listed there might not be for the
latest release. It also lists some https test servers.

We would really like to see a diveerse set of applictions being
tested. Please report any results you have to us.


Kurt


From openssl-users at dukhovni.org  Sat Apr 21 18:45:34 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 21 Apr 2018 14:45:34 -0400
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <20180421184201.GA3191@roeckx.be>
References: <C50FC886-075F-4222-9709-D41F29001FF8@dukhovni.org>
 <CAF8qwaC8wDVzdBnT3PC8-wygO84tXUHADsR7C=jccx06LGBGcw@mail.gmail.com>
 <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
 <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
 <20180420071139.GA32562@roeckx.be> <20180420081141.GA1347@roeckx.be>
 <cf0bd6a2-d31c-677b-696c-efc3171ba9ea@openssl.org>
 <20180421151931.GA19066@roeckx.be> <20180421184201.GA3191@roeckx.be>
Message-ID: <431270C5-3DA3-4A9D-9292-12ADC46CCBAB@dukhovni.org>



> On Apr 21, 2018, at 2:42 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> 
> Here is some attempt:
> 
> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> 1.3 brings a lot of changes that might cause incompatibility. For
> an overview see https://wiki.openssl.org/index.php/TLS1.3

Should the Wiki mention the observed SNI issue?

> We are considering if we should enable TLS 1.3 by default or not,
> or when it should be enabled. For that, we would like to know how
> applications behave with the current version.

It is perhaps unclear in the last sentence what "the current version"
means.

> We would really like to see a diveerse set of applictions being
> tested. Please report any results you have to us.

	s/diveerse/diverse/

-- 
	Viktor.


From kurt at roeckx.be  Sat Apr 21 19:45:30 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 21 Apr 2018 21:45:30 +0200
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <431270C5-3DA3-4A9D-9292-12ADC46CCBAB@dukhovni.org>
References: <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
 <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
 <20180420071139.GA32562@roeckx.be>
 <20180420081141.GA1347@roeckx.be>
 <cf0bd6a2-d31c-677b-696c-efc3171ba9ea@openssl.org>
 <20180421151931.GA19066@roeckx.be>
 <20180421184201.GA3191@roeckx.be>
 <431270C5-3DA3-4A9D-9292-12ADC46CCBAB@dukhovni.org>
Message-ID: <20180421194530.GA5117@roeckx.be>

On Sat, Apr 21, 2018 at 02:45:34PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 21, 2018, at 2:42 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> > 
> > Here is some attempt:
> > 
> > The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> > 1.3 brings a lot of changes that might cause incompatibility. For
> > an overview see https://wiki.openssl.org/index.php/TLS1.3
> 
> Should the Wiki mention the observed SNI issue?

It's really a change in other libraries, but since it can cause
issues, feel free to add it.

> > We are considering if we should enable TLS 1.3 by default or not,
> > or when it should be enabled. For that, we would like to know how
> > applications behave with the current version.
> 
> It is perhaps unclear in the last sentence what "the current version"
> means.

So: with the latest beta release?


Kurt


From openssl-users at dukhovni.org  Sat Apr 21 19:47:03 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 21 Apr 2018 15:47:03 -0400
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <20180421194530.GA5117@roeckx.be>
References: <BD57CF5B-3505-449C-9C44-89F457019639@dukhovni.org>
 <CAF8qwaCvHxi++cNAfmnJTCC4oDQUCdZ-kRkbg7nydwtKQufH1g@mail.gmail.com>
 <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
 <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
 <20180420071139.GA32562@roeckx.be> <20180420081141.GA1347@roeckx.be>
 <cf0bd6a2-d31c-677b-696c-efc3171ba9ea@openssl.org>
 <20180421151931.GA19066@roeckx.be> <20180421184201.GA3191@roeckx.be>
 <431270C5-3DA3-4A9D-9292-12ADC46CCBAB@dukhovni.org>
 <20180421194530.GA5117@roeckx.be>
Message-ID: <674199DC-7782-4DF2-94C1-0EB92B09073F@dukhovni.org>



> On Apr 21, 2018, at 3:45 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> 
>>> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
>>> 1.3 brings a lot of changes that might cause incompatibility. For
>>> an overview see https://wiki.openssl.org/index.php/TLS1.3
>> 
>> Should the Wiki mention the observed SNI issue?
> 
> It's really a change in other libraries, but since it can cause
> issues, feel free to add it.

OK, if find the cycles...

> 
>>> We are considering if we should enable TLS 1.3 by default or not,
>>> or when it should be enabled. For that, we would like to know how
>>> applications behave with the current version.
>> 
>> It is perhaps unclear in the last sentence what "the current version"
>> means.
> 
> So: with the latest beta release?

Yes, that's better.

-- 
	Viktor.


From levitte at openssl.org  Sun Apr 22 16:16:47 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 22 Apr 2018 18:16:47 +0200 (CEST)
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <431270C5-3DA3-4A9D-9292-12ADC46CCBAB@dukhovni.org>
References: <20180421151931.GA19066@roeckx.be>
 <20180421184201.GA3191@roeckx.be>
 <431270C5-3DA3-4A9D-9292-12ADC46CCBAB@dukhovni.org>
Message-ID: <20180422.181647.1323572736099503140.levitte@openssl.org>

In message <431270C5-3DA3-4A9D-9292-12ADC46CCBAB at dukhovni.org> on Sat, 21 Apr 2018 14:45:34 -0400, Viktor Dukhovni <openssl-users at dukhovni.org> said:

openssl-users> > We are considering if we should enable TLS 1.3 by default or not,
openssl-users> > or when it should be enabled. For that, we would like to know how
openssl-users> > applications behave with the current version.
openssl-users> 
openssl-users> It is perhaps unclear in the last sentence what "the current version"
openssl-users> means.

I took that to mean "the 1.1.0 series"

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From openssl-users at dukhovni.org  Mon Apr 23 01:49:42 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 22 Apr 2018 21:49:42 -0400
Subject: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile)
	Postfix to Postfix test
Message-ID: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>


I tested a Postfix server and client built against OpenSSL 1.1.0,
using 1.1.1 run-time libraries.  This exercised peer certificate
fingerprint matching and session resumption.  No major issues.

The only interesting observations are:

  * With TLS 1.3 a new session is generated even sessions are
    resumed, because the server responds with a new ticket
    in the event of session resumption.  With TLS 1.2 sessions
    that had sufficient remaining lifetime did not trigger new
    ticket generation on the server, and no new session was
    stored on the client.  This causes needless wear-and-tear
    on the external session cache in Postfix, since each
    connection writes out a new session, replacing the one
    it just used.  Some might consider this a security feature,
    but it is not especially desirable with SMTP.  Any thoughts
    about whether this could be tunable?  It would have to be
    server-side tuning I think, since the client does not know
    why the server issued a new session, perhaps the old one
    was not (or will soon not) be valid for re-use.


  * Postfix logs a warning when the compile-time and runtime
    libraries are not exactly the same (once per process start),
    this is expected.  Perhaps we should provide a means for
    users to turn that off.

  * The Postfix logging from the new session callback precedes
    the OpenSSL message callback that a session ticket was
    received from the server.  It seems that the OpenSSL message
    callback happens at the completion of session ticket processing,
    but this results in slightly surprising ordering of the logs.
    It seems as though the session is stored before the ticket
    arrives.  I think this "cosmetic" issue may be worth addressing.

----- Client-side diagnostics -----
posttls-finger: warning: run-time library vs. compile-time header version mismatch: OpenSSL 1.1.1 may not be compatible with OpenSSL 1.1.0

posttls-finger: SSL_connect:before SSL initialization
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS read server hello
posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions
posttls-finger: SSL_connect:SSLv3/TLS read server certificate
posttls-finger: SSL_connect:TLSv1.3 read server certificate verify
posttls-finger: SSL_connect:SSLv3/TLS read finished
posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec
posttls-finger: SSL_connect:SSLv3/TLS write finished
posttls-finger: Verified TLS connection established to 127.0.0.1[127.0.0.1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
posttls-finger: SSL_connect:SSL negotiation finished successfully
posttls-finger: SSL_connect:SSL negotiation finished successfully
posttls-finger: save session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D to memory cache
posttls-finger: SSL_connect:SSLv3/TLS read server session ticket

posttls-finger: Reconnecting after 1 seconds
posttls-finger: looking for session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D in memory cache
posttls-finger: reloaded session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D from memory cache
posttls-finger: SSL_connect:before SSL initialization
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS read server hello
posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions
posttls-finger: SSL_connect:SSLv3/TLS read finished
posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec
posttls-finger: SSL_connect:SSLv3/TLS write finished
posttls-finger: 127.0.0.1[127.0.0.1]:25: Reusing old session
posttls-finger: Verified TLS connection established to 127.0.0.1[127.0.0.1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
posttls-finger: SSL_connect:SSL negotiation finished successfully
posttls-finger: SSL_connect:SSL negotiation finished successfully
posttls-finger: save session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D to memory cache
posttls-finger: SSL_connect:SSLv3/TLS read server session ticket
----- End -----


-- 
	Viktor.


From levitte at openssl.org  Mon Apr 23 02:10:42 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 23 Apr 2018 04:10:42 +0200 (CEST)
Subject: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile)
 Postfix to Postfix test
In-Reply-To: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>
References: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>
Message-ID: <20180423.041042.420814945818906720.levitte@openssl.org>

In message <E89D6B11-7D8A-4408-A96E-28E519AE0BC0 at dukhovni.org> on Sun, 22 Apr 2018 21:49:42 -0400, Viktor Dukhovni <openssl-users at dukhovni.org> said:

openssl-users>   * Postfix logs a warning when the compile-time and runtime
openssl-users>     libraries are not exactly the same (once per process start),
openssl-users>     this is expected.  Perhaps we should provide a means for
openssl-users>     users to turn that off.

With our current version scheme, you should use the compatibility mask
0xFFF00000
(maybe we should have that value in opensslv.h...  Matthias St. Pierre
might have an idea or two on the matter, too)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From matt at openssl.org  Mon Apr 23 07:21:38 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 23 Apr 2018 08:21:38 +0100
Subject: [openssl-project] FW: [Curdle] I-D Action:
 draft-ietf-curdle-pkix-09.txt
In-Reply-To: <E2483EB8-7106-4F80-8045-25C3A0310CD2@akamai.com>
References: <152425941070.27142.12037456561613339150@ietfa.amsl.com>
 <E2483EB8-7106-4F80-8045-25C3A0310CD2@akamai.com>
Message-ID: <cb1da424-2e88-c3ed-7e77-f97e6cbb07db@openssl.org>



On 21/04/18 13:22, Salz, Rich wrote:
> Anyone up for a doing a PR that adds these to objects.txt?

They're already in there:

https://github.com/openssl/openssl/blob/master/crypto/objects/objects.txt#L1581

Matt



> 
> ?On 4/20/18, 5:23 PM, "internet-drafts at ietf.org" <internet-drafts at ietf.org> wrote:
> 
>     
>     A New Internet-Draft is available from the on-line Internet-Drafts directories.
>     This draft is a work item of the CURves, Deprecating and a Little more Encryption WG of the IETF.
>     
>             Title           : Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure
>             Authors         : Simon Josefsson
>                               Jim Schaad
>     	Filename        : draft-ietf-curdle-pkix-09.txt
>     	Pages           : 18
>     	Date            : 2018-04-20
>     
>     Abstract:
>        This document specifies algorithm identifiers and ASN.1 encoding
>        formats for Elliptic Curve constructs using the curve25519 and
>        curve448 curves.  The signature algorithms covered are Ed25519 and
>        Ed448.  The key agreement algorithm covered are X25519 and X448.  The
>        encoding for Public Key, Private Key and EdDSA digital signature
>        structures is provided.
>     
>     
>     The IETF datatracker status page for this draft is:
>     https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
>     
>     There are also htmlized versions available at:
>     https://tools.ietf.org/html/draft-ietf-curdle-pkix-09
>     https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-09
>     
>     A diff from the previous version is available at:
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-09
>     
>     
>     Please note that it may take a couple of minutes from the time of submission
>     until the htmlized version and diff are available at tools.ietf.org.
>     
>     Internet-Drafts are also available by anonymous FTP at:
>     ftp://ftp.ietf.org/internet-drafts/
>     
>     _______________________________________________
>     Curdle mailing list
>     Curdle at ietf.org
>     https://www.ietf.org/mailman/listinfo/curdle
>     
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 

From matt at openssl.org  Mon Apr 23 07:35:48 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 23 Apr 2018 08:35:48 +0100
Subject: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile)
 Postfix to Postfix test
In-Reply-To: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>
References: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>
Message-ID: <c273ab82-d892-88b8-e096-11820154f95c@openssl.org>



On 23/04/18 02:49, Viktor Dukhovni wrote:
> 
> I tested a Postfix server and client built against OpenSSL 1.1.0,
> using 1.1.1 run-time libraries.  This exercised peer certificate
> fingerprint matching and session resumption.  No major issues.
> 
> The only interesting observations are:
> 
>   * With TLS 1.3 a new session is generated even sessions are
>     resumed, because the server responds with a new ticket
>     in the event of session resumption.  With TLS 1.2 sessions
>     that had sufficient remaining lifetime did not trigger new
>     ticket generation on the server, and no new session was
>     stored on the client.  This causes needless wear-and-tear
>     on the external session cache in Postfix, since each
>     connection writes out a new session, replacing the one
>     it just used.  Some might consider this a security feature,
>     but it is not especially desirable with SMTP.  Any thoughts
>     about whether this could be tunable?  It would have to be
>     server-side tuning I think, since the client does not know
>     why the server issued a new session, perhaps the old one
>     was not (or will soon not) be valid for re-use.

Note that some servers may actually issue more than one ticket per
connection. Notably boring issues 2 by default. I'm not sure if they
enable configuration of that.

In servers that accept early data we enforce single use tickets. In
those scenarios it may make sense to have more than one ticket issued
per connection.

I do have a WIP PR for enabling configuration of the number of tickets
to be sent on the server side:

https://github.com/openssl/openssl/pull/5227

I have not been prioritising that at the moment because I have been
focussing more on fixing defects.

Matt

From kurt at roeckx.be  Mon Apr 23 19:45:32 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 23 Apr 2018 21:45:32 +0200
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180407.165806.463561558996899206.levitte@openssl.org>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403165409.GA22094@roeckx.be>
 <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>
 <20180407.165806.463561558996899206.levitte@openssl.org>
Message-ID: <20180423194532.GA9229@roeckx.be>

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


From openssl-users at dukhovni.org  Mon Apr 23 21:38:58 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 23 Apr 2018 17:38:58 -0400
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <20180422.181647.1323572736099503140.levitte@openssl.org>
References: <20180421151931.GA19066@roeckx.be>
 <20180421184201.GA3191@roeckx.be>
 <431270C5-3DA3-4A9D-9292-12ADC46CCBAB@dukhovni.org>
 <20180422.181647.1323572736099503140.levitte@openssl.org>
Message-ID: <C500C76A-DE13-4749-BCF2-E127F8CFA174@dukhovni.org>



> On Apr 22, 2018, at 12:16 PM, Richard Levitte <levitte at openssl.org> wrote:
> 
> openssl-users> > We are considering if we should enable TLS 1.3 by default or not,
> openssl-users> > or when it should be enabled. For that, we would like to know how
> openssl-users> > applications behave with the current version.
> openssl-users> 
> openssl-users> It is perhaps unclear in the last sentence what "the current version"
> openssl-users> means.
> 
> I took that to mean "the 1.1.0 series"

I meant unclear to potential readers, rather than project maintainers. :-)

-- 
	Viktor.


From paul.dale at oracle.com  Mon Apr 23 22:31:39 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Mon, 23 Apr 2018 15:31:39 -0700 (PDT)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180423194532.GA9229@roeckx.be>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403165409.GA22094@roeckx.be>
 <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>
 <20180407.165806.463561558996899206.levitte@openssl.org>
 <20180423194532.GA9229@roeckx.be>
Message-ID: <6f707b9d-3a18-4912-9685-bc23a0714a5e@default>

I can possibly provide some input having done similar for a number of platforms and written faster but equivalent entropy assessment code to NIST's (for the second draft of SP 800-90B rather than the final version).

I'm not knowledgeable about VMS though.

We could discuss further at ICMC if you're in the area.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: Kurt Roeckx [mailto:kurt at roeckx.be] 
Sent: Tuesday, 24 April 2018 5:46 AM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] Entropy seeding the DRBG

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 at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

From openssl-users at dukhovni.org  Mon Apr 23 23:16:44 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 23 Apr 2018 19:16:44 -0400
Subject: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile)
 Postfix to Postfix test
In-Reply-To: <c273ab82-d892-88b8-e096-11820154f95c@openssl.org>
References: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>
 <c273ab82-d892-88b8-e096-11820154f95c@openssl.org>
Message-ID: <6D593FF9-4979-4BEC-88BE-1BAE0562A44C@dukhovni.org>



> On Apr 23, 2018, at 3:35 AM, Matt Caswell <matt at openssl.org> wrote:
> 
>>  * With TLS 1.3 a new session is generated even sessions are
>>    resumed, because the server responds with a new ticket
>>    in the event of session resumption.  With TLS 1.2 sessions
>>    that had sufficient remaining lifetime did not trigger new
>>    ticket generation on the server, and no new session was
>>    stored on the client.  This causes needless wear-and-tear
>>    on the external session cache in Postfix, since each
>>    connection writes out a new session, replacing the one
>>    it just used.  Some might consider this a security feature,
>>    but it is not especially desirable with SMTP.  Any thoughts
>>    about whether this could be tunable?  It would have to be
>>    server-side tuning I think, since the client does not know
>>    why the server issued a new session, perhaps the old one
>>    was not (or will soon not) be valid for re-use.
> 
> Note that some servers may actually issue more than one ticket per
> connection. Notably boring issues 2 by default. I'm not sure if they
> enable configuration of that.

To be clear, I'm looking for server-side controls, so that, for example,
in the Postfix SMTP server when the presented ticket has sufficient
lifetime left (as is the case with TLS 1.2), no new session tickets
are generated.  The Postfix SMTP server sets up a ticket callback:

  https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L303

and so can signal the SSL engine to accept or re-issue the ticket.
Presently tickets are always accepted and periodically a new
handshake takes place when the ticket is no longer valid.

> In servers that accept early data we enforce single use tickets. In
> those scenarios it may make sense to have more than one ticket issued
> per connection.

There's no early data in SMTP STARTTLS.

> I do have a WIP PR for enabling configuration of the number of tickets
> to be sent on the server side:
> 
> https://github.com/openssl/openssl/pull/5227
> 
> I have not been prioritising that at the moment because I have been
> focussing more on fixing defects.

I'll take a look...

-- 
	Viktor.


From openssl-users at dukhovni.org  Tue Apr 24 01:34:18 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 23 Apr 2018 21:34:18 -0400
Subject: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile)
 Postfix to Postfix test
In-Reply-To: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>
References: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>
Message-ID: <DCD2CF0B-FAD5-4245-BFD9-B9290FDE083B@dukhovni.org>



> On Apr 22, 2018, at 9:49 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> ----- Client-side diagnostics -----

On the server side I see that even when the ticket callback returns "0" to accept and not re-issue the ticket, a new ticket is requested anyway.  I'd like to be able to control this, and not issue new tickets when the present ticket is acceptable.  If this requires new API entry points, I can condition them on a suitable min library version.  But ideally the callback return value will be honoured, I don't yet see why we would not do that.

----- Server-side diagnostics -----
Initial session:
----------------

SSL_accept:before SSL initialization
SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write change cipher spec
SSL_accept:TLSv1.3 write encrypted extensions
SSL_accept:SSLv3/TLS write certificate
SSL_accept:TLSv1.3 write server certificate verify
SSL_accept:SSLv3/TLS write finished
SSL_accept:TLSv1.3 early data
SSL_accept:TLSv1.3 early data
SSL_accept:SSLv3/TLS read finished
>>> Callback log entry, create initial ticket:
  Issuing session ticket, key expiration: 1524534619
SSL_accept:SSLv3/TLS write session ticket
>>> Post-handshake SMTP server log entry:
  Anonymous TLS connection established from localhost[127.0.0.1]:
    TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)

Resumed session:
----------------
SSL_accept:before SSL initialization
SSL_accept:before SSL initialization
>>> Callback log entry, decrypting presented ticket:
  Decrypting session ticket, key expiration: 1524534619
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write change cipher spec
SSL_accept:TLSv1.3 write encrypted extensions
SSL_accept:SSLv3/TLS write finished
SSL_accept:TLSv1.3 early data
SSL_accept:TLSv1.3 early data
SSL_accept:SSLv3/TLS read finished
>>> Callback asked to create a new ticket:
  Issuing session ticket, key expiration: 1524534619
SSL_accept:SSLv3/TLS write session ticket
>>> Post-handshake application logging:
  Reusing old session (RFC 5077 session ticket)
  Anonymous TLS connection established from localhost[127.0.0.1]:
  TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
----- End -----

-- 
	Viktor.


From levitte at openssl.org  Tue Apr 24 05:20:42 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 24 Apr 2018 07:20:42 +0200
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <6f707b9d-3a18-4912-9685-bc23a0714a5e@default>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403165409.GA22094@roeckx.be>
 <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>
 <20180407.165806.463561558996899206.levitte@openssl.org>
 <20180423194532.GA9229@roeckx.be>
 <6f707b9d-3a18-4912-9685-bc23a0714a5e@default>
Message-ID: <DE10C5F0-7321-4CDF-A2D7-8F3FE4B4DC95@openssl.org>

Like I think I mentioned a few days ago, I'm currently on a conference. I'll take this up in more depth later this week.

I have a question, though... Kurt said at some point that all that was needed on the VMS side was to collect data, the rest can be done elsewhere (thankfully). However, I don't really understand what the collected data is supposed to be. Just the same stream of bytes that I would feed the entropy acquisition, or something else? Is the time delta between samples a factor in this?

Cheers
Richard 

Paul Dale <paul.dale at oracle.com> skrev: (24 april 2018 00:31:39 CEST)
>I can possibly provide some input having done similar for a number of
>platforms and written faster but equivalent entropy assessment code to
>NIST's (for the second draft of SP 800-90B rather than the final
>version).
>
>I'm not knowledgeable about VMS though.
>
>We could discuss further at ICMC if you're in the area.
>
>
>Pauli

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From kaduk at mit.edu  Tue Apr 24 13:29:50 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Tue, 24 Apr 2018 08:29:50 -0500
Subject: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile)
 Postfix to Postfix test
In-Reply-To: <DCD2CF0B-FAD5-4245-BFD9-B9290FDE083B@dukhovni.org>
References: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>
 <DCD2CF0B-FAD5-4245-BFD9-B9290FDE083B@dukhovni.org>
Message-ID: <20180424132950.GF93779@kduck.kaduk.org>

On Mon, Apr 23, 2018 at 09:34:18PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 22, 2018, at 9:49 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> > 
> > ----- Client-side diagnostics -----
> 
> On the server side I see that even when the ticket callback returns "0" to accept and not re-issue the ticket, a new ticket is requested anyway.  I'd like to be able to control this, and not issue new tickets when the present ticket is acceptable.  If this requires new API entry points, I can condition them on a suitable min library version.  But ideally the callback return value will be honoured, I don't yet see why we would not do that.

To be clear, the current draft explicitly says "Servers SHOULD issue
new tickets with every connection."  This is not a MUST, but is
perhaps strong enough guidance to merit overriding the existing
ticket callback semantics.

-Ben

From openssl-users at dukhovni.org  Tue Apr 24 14:21:28 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 24 Apr 2018 10:21:28 -0400
Subject: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile)
 Postfix to Postfix test
In-Reply-To: <20180424132950.GF93779@kduck.kaduk.org>
References: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>
 <DCD2CF0B-FAD5-4245-BFD9-B9290FDE083B@dukhovni.org>
 <20180424132950.GF93779@kduck.kaduk.org>
Message-ID: <00743181-CA0A-4E5B-9E49-E82B26CDE33A@dukhovni.org>



> On Apr 24, 2018, at 9:29 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:
> 
> To be clear, the current draft explicitly says "Servers SHOULD issue
> new tickets with every connection."  This is not a MUST, but is
> perhaps strong enough guidance to merit overriding the existing
> ticket callback semantics.

Fine advice for browsers, but not terribly useful for Postfix.
Multiple processes read and write the session cache in parallel,
and single-use tickets won't work without serialization and
multiple cache slots for the same destination.

The Postfix SMTP server needs to be able to issue tickets only
as-needed on the server.  The TLS 1.2 model works just fine for
SMTP and STEKs are already properly rotated.

I think that the previous behaviour of the callback needs to
continue to apply, if the callback does not return re-issue,
no new ticket should be returned.  The callback has access
to the SSL handle and can determine the protocol version
if it so chooses.

The built-in ticket callback can always re-issue if that's
the preferred default.

-- 
	Viktor.


From kurt at roeckx.be  Tue Apr 24 17:24:40 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 24 Apr 2018 19:24:40 +0200
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <DE10C5F0-7321-4CDF-A2D7-8F3FE4B4DC95@openssl.org>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403165409.GA22094@roeckx.be>
 <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>
 <20180407.165806.463561558996899206.levitte@openssl.org>
 <20180423194532.GA9229@roeckx.be>
 <6f707b9d-3a18-4912-9685-bc23a0714a5e@default>
 <DE10C5F0-7321-4CDF-A2D7-8F3FE4B4DC95@openssl.org>
Message-ID: <20180424172439.GA8068@roeckx.be>

On Tue, Apr 24, 2018 at 07:20:42AM +0200, Richard Levitte wrote:
> Like I think I mentioned a few days ago, I'm currently on a conference. I'll take this up in more depth later this week.
> 
> I have a question, though... Kurt said at some point that all that was needed on the VMS side was to collect data, the rest can be done elsewhere (thankfully). However, I don't really understand what the collected data is supposed to be. Just the same stream of bytes that I would feed the entropy acquisition, or something else? Is the time delta between samples a factor in this?

The API support getting data that has 1 bit of entropy per 128 bit
received (DRBG_MINMAX_FACTOR). If it's worse than that, you might
have to write your own extract method.

A stream of bytes it just fine.

I think the tme delta will really depend on your source. If it really
changes all the time, it really doesn't matter much how fast you
do it. But I think some (most?) of the variables don't change that
often.


Kurt


From paul.dale at oracle.com  Wed Apr 25 21:20:46 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Wed, 25 Apr 2018 14:20:46 -0700 (PDT)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180424172439.GA8068@roeckx.be>
References: <DA29A952-D1E7-44ED-8BE9-115E073A517B@akamai.com>
 <20180403165409.GA22094@roeckx.be>
 <8C39CDF4-A91E-4DFB-BE67-6799E07D3AB7@akamai.com>
 <20180407.165806.463561558996899206.levitte@openssl.org>
 <20180423194532.GA9229@roeckx.be>
 <6f707b9d-3a18-4912-9685-bc23a0714a5e@default>
 <DE10C5F0-7321-4CDF-A2D7-8F3FE4B4DC95@openssl.org>
 <20180424172439.GA8068@roeckx.be>
Message-ID: <f7110d51-d1fb-4d8f-8e6e-545f4ac95d65@default>

A stream of bytes.  They don't need to contain eight bit data.

NIST's SP 800-90B wants 1,000,000 bytes to do the estimation (there are restart tests as well worry about them after good sources are determined).  The source shouldn't be manipulated with anything other than xor -- a wide source can be thinned by xoring the bytes together but not by shifting and xoring e.g.

I suspect you'll be sampling the sources periodically -- this is OS and workload dependent.  Even for a continuously changing good source, you'll want to sample slower to avoid impacting the CPU too much.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-----Original Message-----
From: Kurt Roeckx [mailto:kurt at roeckx.be] 
Sent: Wednesday, 25 April 2018 3:25 AM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] Entropy seeding the DRBG

On Tue, Apr 24, 2018 at 07:20:42AM +0200, Richard Levitte wrote:
> Like I think I mentioned a few days ago, I'm currently on a conference. I'll take this up in more depth later this week.
> 
> I have a question, though... Kurt said at some point that all that was needed on the VMS side was to collect data, the rest can be done elsewhere (thankfully). However, I don't really understand what the collected data is supposed to be. Just the same stream of bytes that I would feed the entropy acquisition, or something else? Is the time delta between samples a factor in this?

The API support getting data that has 1 bit of entropy per 128 bit received (DRBG_MINMAX_FACTOR). If it's worse than that, you might have to write your own extract method.

A stream of bytes it just fine.

I think the tme delta will really depend on your source. If it really changes all the time, it really doesn't matter much how fast you do it. But I think some (most?) of the variables don't change that often.


Kurt

_______________________________________________
openssl-project mailing list
openssl-project at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

From levitte at openssl.org  Thu Apr 26 13:57:27 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 26 Apr 2018 15:57:27 +0200
Subject: [openssl-project] Upcoming 1.1.1 audit?
Message-ID: <D7636315-D351-4D7B-AF6C-3CD48550BF00@openssl.org>

I kept seeing tweets about a future OSTIF audit, and just saw that they now have funding:

https://twitter.com/OSTIFofficial/status/989421638960713728

Is this interesting to us? Should we synchronize with them?

Cheers
Richard 
-- 
Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet.

From matt at openssl.org  Thu Apr 26 13:59:01 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 26 Apr 2018 14:59:01 +0100
Subject: [openssl-project] Upcoming 1.1.1 audit?
In-Reply-To: <D7636315-D351-4D7B-AF6C-3CD48550BF00@openssl.org>
References: <D7636315-D351-4D7B-AF6C-3CD48550BF00@openssl.org>
Message-ID: <16d990c5-ada7-c10c-91c1-ac3c06160a03@openssl.org>

They have been talking to us over a long period about this audit (there
have been a number of emails to OMC about it). I've not heard anything
from them recently though.

Matt


On 26/04/18 14:57, Richard Levitte wrote:
> I kept seeing tweets about a future OSTIF audit, and just saw that they now have funding:
> 
> https://twitter.com/OSTIFofficial/status/989421638960713728
> 
> Is this interesting to us? Should we synchronize with them?
> 
> Cheers
> Richard 
> 

From matt at openssl.org  Fri Apr 27 11:02:44 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 27 Apr 2018 12:02:44 +0100
Subject: [openssl-project] Beta release on Tuesday
Message-ID: <8b047c59-1c55-6dff-06b4-1bc972bf1b33@openssl.org>

As normal we are planning a new beta release on Tuesday. This means that
we will be freezing the repo from Monday afternoon (UTC).

Richard will not be available to review the release so I'm looking for a
volunteer to fill that role. Any takers?

Thanks

Matt

From rsalz at akamai.com  Fri Apr 27 11:12:40 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 27 Apr 2018 11:12:40 +0000
Subject: [openssl-project] Beta release on Tuesday
In-Reply-To: <8b047c59-1c55-6dff-06b4-1bc972bf1b33@openssl.org>
References: <8b047c59-1c55-6dff-06b4-1bc972bf1b33@openssl.org>
Message-ID: <739E4C99-8D3D-4B45-9D05-5836C431D24C@akamai.com>

>    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.



From kurt at roeckx.be  Fri Apr 27 21:29:28 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 27 Apr 2018 23:29:28 +0200
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <674199DC-7782-4DF2-94C1-0EB92B09073F@dukhovni.org>
References: <fecf7e31-bd55-b924-af70-4114f240a08f@openssl.org>
 <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
 <20180420071139.GA32562@roeckx.be>
 <20180420081141.GA1347@roeckx.be>
 <cf0bd6a2-d31c-677b-696c-efc3171ba9ea@openssl.org>
 <20180421151931.GA19066@roeckx.be>
 <20180421184201.GA3191@roeckx.be>
 <431270C5-3DA3-4A9D-9292-12ADC46CCBAB@dukhovni.org>
 <20180421194530.GA5117@roeckx.be>
 <674199DC-7782-4DF2-94C1-0EB92B09073F@dukhovni.org>
Message-ID: <20180427212928.GA5836@roeckx.be>

On Sat, Apr 21, 2018 at 03:47:03PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 21, 2018, at 3:45 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> > 
> >>> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> >>> 1.3 brings a lot of changes that might cause incompatibility. For
> >>> an overview see https://wiki.openssl.org/index.php/TLS1.3
> >> 
> >> Should the Wiki mention the observed SNI issue?
> > 
> > It's really a change in other libraries, but since it can cause
> > issues, feel free to add it.
> 
> OK, if find the cycles...

I've added a section on that page about it.


Kurt


From kurt at roeckx.be  Sat Apr 28 18:41:23 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 28 Apr 2018 20:41:23 +0200
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <20180427212928.GA5836@roeckx.be>
References: <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
 <20180420071139.GA32562@roeckx.be>
 <20180420081141.GA1347@roeckx.be>
 <cf0bd6a2-d31c-677b-696c-efc3171ba9ea@openssl.org>
 <20180421151931.GA19066@roeckx.be>
 <20180421184201.GA3191@roeckx.be>
 <431270C5-3DA3-4A9D-9292-12ADC46CCBAB@dukhovni.org>
 <20180421194530.GA5117@roeckx.be>
 <674199DC-7782-4DF2-94C1-0EB92B09073F@dukhovni.org>
 <20180427212928.GA5836@roeckx.be>
Message-ID: <20180428184123.GA1298@roeckx.be>

On Fri, Apr 27, 2018 at 11:29:28PM +0200, Kurt Roeckx wrote:
> On Sat, Apr 21, 2018 at 03:47:03PM -0400, Viktor Dukhovni wrote:
> > 
> > 
> > > On Apr 21, 2018, at 3:45 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> > > 
> > >>> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> > >>> 1.3 brings a lot of changes that might cause incompatibility. For
> > >>> an overview see https://wiki.openssl.org/index.php/TLS1.3
> > >> 
> > >> Should the Wiki mention the observed SNI issue?
> > > 
> > > It's really a change in other libraries, but since it can cause
> > > issues, feel free to add it.
> > 
> > OK, if find the cycles...
> 
> I've added a section on that page about it.

So should I send that mail?


Kurt


From openssl-users at dukhovni.org  Sat Apr 28 20:32:42 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 28 Apr 2018 16:32:42 -0400
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <20180428184123.GA1298@roeckx.be>
References: <C52E12D5-21DB-4FB6-AEED-A873D7364E02@dukhovni.org>
 <20180420071139.GA32562@roeckx.be> <20180420081141.GA1347@roeckx.be>
 <cf0bd6a2-d31c-677b-696c-efc3171ba9ea@openssl.org>
 <20180421151931.GA19066@roeckx.be> <20180421184201.GA3191@roeckx.be>
 <431270C5-3DA3-4A9D-9292-12ADC46CCBAB@dukhovni.org>
 <20180421194530.GA5117@roeckx.be>
 <674199DC-7782-4DF2-94C1-0EB92B09073F@dukhovni.org>
 <20180427212928.GA5836@roeckx.be> <20180428184123.GA1298@roeckx.be>
Message-ID: <8EE26142-3CAD-4E79-AFA4-38B48F9FEEAB@dukhovni.org>



> On Apr 28, 2018, at 2:41 PM, Kurt Roeckx <kurt at 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...

-- 
	Viktor.


From kaduk at mit.edu  Sun Apr 29 00:42:41 2018
From: kaduk at mit.edu (Benjamin Kaduk)
Date: Sat, 28 Apr 2018 19:42:41 -0500
Subject: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile)
 Postfix to Postfix test
In-Reply-To: <00743181-CA0A-4E5B-9E49-E82B26CDE33A@dukhovni.org>
References: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>
 <DCD2CF0B-FAD5-4245-BFD9-B9290FDE083B@dukhovni.org>
 <20180424132950.GF93779@kduck.kaduk.org>
 <00743181-CA0A-4E5B-9E49-E82B26CDE33A@dukhovni.org>
Message-ID: <20180429004241.GC96137@kduck.kaduk.org>

On Tue, Apr 24, 2018 at 10:21:28AM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 24, 2018, at 9:29 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:
> > 
> > To be clear, the current draft explicitly says "Servers SHOULD issue
> > new tickets with every connection."  This is not a MUST, but is
> > perhaps strong enough guidance to merit overriding the existing
> > ticket callback semantics.
> 
> Fine advice for browsers, but not terribly useful for Postfix.
> Multiple processes read and write the session cache in parallel,
> and single-use tickets won't work without serialization and
> multiple cache slots for the same destination.
> 
> The Postfix SMTP server needs to be able to issue tickets only
> as-needed on the server.  The TLS 1.2 model works just fine for
> SMTP and STEKs are already properly rotated.

I'm not trying to say that Postfix or even SMTP in general needs to
adopt the TLS 1.3 (Web) model; I'm only trying to consider the
OpenSSL 1.1.1 library default, which I think ought to honor the
SHOULD in the spec.

> I think that the previous behaviour of the callback needs to
> continue to apply, if the callback does not return re-issue,
> no new ticket should be returned.  The callback has access
> to the SSL handle and can determine the protocol version
> if it so chooses.

and will not automatically update to TLS 1.3 semantics by default.
But maybe that's okay.

> The built-in ticket callback can always re-issue if that's
> the preferred default.

I think that is the preferred default, and would not object to
implementing the default in the built-in ticket callback if you
insist on Postfix not having to change its callback to get its
preferred behavior.

-Ben

From openssl-users at dukhovni.org  Sun Apr 29 04:25:10 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 29 Apr 2018 00:25:10 -0400
Subject: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile)
 Postfix to Postfix test
In-Reply-To: <20180429004241.GC96137@kduck.kaduk.org>
References: <E89D6B11-7D8A-4408-A96E-28E519AE0BC0@dukhovni.org>
 <DCD2CF0B-FAD5-4245-BFD9-B9290FDE083B@dukhovni.org>
 <20180424132950.GF93779@kduck.kaduk.org>
 <00743181-CA0A-4E5B-9E49-E82B26CDE33A@dukhovni.org>
 <20180429004241.GC96137@kduck.kaduk.org>
Message-ID: <770C95FC-95BC-4ED3-ADB3-C9D8C9DE7772@dukhovni.org>

> On Apr 28, 2018, at 8:42 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
> 

> [ ... nothing I don't agree with ... ]


We're on the same page here.  OpenSSL the built-in defualt
callback can re-issue by default, so long as custom callbacks
can choose to not re-issue (their return code is honoured).

My other observation is that multi-issue should only happen
on initial handshakes, otherways if we issue "k > 1" tickets
even on resumption, then after "N" connections we get N*k
tickets, which is silly.

-- 
	Viktor.


From kurt at roeckx.be  Sun Apr 29 10:43:51 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 29 Apr 2018 12:43:51 +0200
Subject: [openssl-project] When to enable TLS 1.3
In-Reply-To: <8EE26142-3CAD-4E79-AFA4-38B48F9FEEAB@dukhovni.org>
References: <20180420081141.GA1347@roeckx.be>
 <cf0bd6a2-d31c-677b-696c-efc3171ba9ea@openssl.org>
 <20180421151931.GA19066@roeckx.be>
 <20180421184201.GA3191@roeckx.be>
 <431270C5-3DA3-4A9D-9292-12ADC46CCBAB@dukhovni.org>
 <20180421194530.GA5117@roeckx.be>
 <674199DC-7782-4DF2-94C1-0EB92B09073F@dukhovni.org>
 <20180427212928.GA5836@roeckx.be> <20180428184123.GA1298@roeckx.be>
 <8EE26142-3CAD-4E79-AFA4-38B48F9FEEAB@dukhovni.org>
Message-ID: <20180429104350.GA21297@roeckx.be>

On Sat, Apr 28, 2018 at 04:32:42PM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 28, 2018, at 2:41 PM, Kurt Roeckx <kurt at 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


From levitte at openssl.org  Mon Apr 30 12:42:53 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 30 Apr 2018 14:42:53 +0200 (CEST)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180424172439.GA8068@roeckx.be>
References: <6f707b9d-3a18-4912-9685-bc23a0714a5e@default>
 <DE10C5F0-7321-4CDF-A2D7-8F3FE4B4DC95@openssl.org>
 <20180424172439.GA8068@roeckx.be>
Message-ID: <20180430.144253.1714680705314385876.levitte@openssl.org>

In message <20180424172439.GA8068 at roeckx.be> on Tue, 24 Apr 2018 19:24:40 +0200, Kurt Roeckx <kurt at roeckx.be> said:

kurt> On Tue, Apr 24, 2018 at 07:20:42AM +0200, Richard Levitte wrote:
kurt> > Like I think I mentioned a few days ago, I'm currently on a conference. I'll take this up in more depth later this week.
kurt> > 
kurt> > I have a question, though... Kurt said at some point that all that was needed on the VMS side was to collect data, the rest can be done elsewhere (thankfully). However, I don't really understand what the collected data is supposed to be. Just the same stream of bytes that I would feed the entropy acquisition, or something else? Is the time delta between samples a factor in this?
kurt> 
kurt> The API support getting data that has 1 bit of entropy per 128 bit
kurt> received (DRBG_MINMAX_FACTOR). If it's worse than that, you might
kurt> have to write your own extract method.

I might have to either way, don't I.  A method I'm pondering is to
pass all the data gathered (700-something bytes) through sha512 and
add the result to the pool.  I have no idea what that says about the
entropy of the original data, which is at somewhere between 0.1 and
0.2 entropy bits per data bit according the 3rd order entropy
calculation that I replicated from the Linux /dev/urandom driver.

kurt> A stream of bytes it just fine.
kurt> 
kurt> I think the tme delta will really depend on your source. If it
kurt> really changes all the time, it really doesn't matter much how
kurt> fast you do it. But I think some (most?) of the variables don't
kurt> change that often.

It doesn't change *all* the time, but with a 1-10 second sleep between
data gatherings, there's always *something* that has changed enough
to give a 3rd order diff from previous sampling that's > 0.

So what I've done for now is to make two files, one that's the raw
data, repeatedly gathered every 1-10 seconds until I got about 1 Mib
of data, the other being a concatenation of sha512 calculations of
those same (*) data until I filled that file up to 1 Mib.  I suspect
that the latter isn't quite valid, considering Paul said something
about no transformation whatsoever, but I thought it would be worth a
try.

I'll have to try and feed this to the entropy test programs you
indicated earlier...

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rsalz at akamai.com  Mon Apr 30 13:05:58 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 30 Apr 2018 13:05:58 +0000
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180430.144253.1714680705314385876.levitte@openssl.org>
References: <6f707b9d-3a18-4912-9685-bc23a0714a5e@default>
 <DE10C5F0-7321-4CDF-A2D7-8F3FE4B4DC95@openssl.org>
 <20180424172439.GA8068@roeckx.be>
 <20180430.144253.1714680705314385876.levitte@openssl.org>
Message-ID: <B4C4F4F3-A0A6-4DC3-AFFA-A72239694960@akamai.com>

>    pass all the data gathered (700-something bytes) through sha512 and
    add the result to the pool.

I don't see a reason to hash it, just send it all 


From kurt at roeckx.be  Mon Apr 30 13:10:01 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 30 Apr 2018 15:10:01 +0200
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180430.144253.1714680705314385876.levitte@openssl.org>
References: <6f707b9d-3a18-4912-9685-bc23a0714a5e@default>
 <DE10C5F0-7321-4CDF-A2D7-8F3FE4B4DC95@openssl.org>
 <20180424172439.GA8068@roeckx.be>
 <20180430.144253.1714680705314385876.levitte@openssl.org>
Message-ID: <20180430131000.GA25216@roeckx.be>

On Mon, Apr 30, 2018 at 02:42:53PM +0200, Richard Levitte wrote:
> In message <20180424172439.GA8068 at roeckx.be> on Tue, 24 Apr 2018 19:24:40 +0200, Kurt Roeckx <kurt at roeckx.be> said:
> 
> kurt> On Tue, Apr 24, 2018 at 07:20:42AM +0200, Richard Levitte wrote:
> kurt> > Like I think I mentioned a few days ago, I'm currently on a conference. I'll take this up in more depth later this week.
> kurt> > 
> kurt> > I have a question, though... Kurt said at some point that all that was needed on the VMS side was to collect data, the rest can be done elsewhere (thankfully). However, I don't really understand what the collected data is supposed to be. Just the same stream of bytes that I would feed the entropy acquisition, or something else? Is the time delta between samples a factor in this?
> kurt> 
> kurt> The API support getting data that has 1 bit of entropy per 128 bit
> kurt> received (DRBG_MINMAX_FACTOR). If it's worse than that, you might
> kurt> have to write your own extract method.
> 
> I might have to either way, don't I.  A method I'm pondering is to
> pass all the data gathered (700-something bytes) through sha512 and
> add the result to the pool.  I have no idea what that says about the
> entropy of the original data, which is at somewhere between 0.1 and
> 0.2 entropy bits per data bit according the 3rd order entropy
> calculation that I replicated from the Linux /dev/urandom driver.
> 
> kurt> A stream of bytes it just fine.
> kurt> 
> kurt> I think the tme delta will really depend on your source. If it
> kurt> really changes all the time, it really doesn't matter much how
> kurt> fast you do it. But I think some (most?) of the variables don't
> kurt> change that often.
> 
> It doesn't change *all* the time, but with a 1-10 second sleep between
> data gatherings, there's always *something* that has changed enough
> to give a 3rd order diff from previous sampling that's > 0.
> 
> So what I've done for now is to make two files, one that's the raw
> data, repeatedly gathered every 1-10 seconds until I got about 1 Mib
> of data, the other being a concatenation of sha512 calculations of
> those same (*) data until I filled that file up to 1 Mib.  I suspect
> that the latter isn't quite valid, considering Paul said something
> about no transformation whatsoever, but I thought it would be worth a
> try.

The comment about not hashing it is if you want to use the tool to
do entropy estimation. Hashing it will not increase the entropy,
but the estimation will be totally wrong.

Passing the hashed data to the drbg as entropy input is fine if
you already know how much entropy that it contains.


Kurt


From levitte at openssl.org  Mon Apr 30 13:26:09 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 30 Apr 2018 15:26:09 +0200 (CEST)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180430131000.GA25216@roeckx.be>
References: <20180424172439.GA8068@roeckx.be>
 <20180430.144253.1714680705314385876.levitte@openssl.org>
 <20180430131000.GA25216@roeckx.be>
Message-ID: <20180430.152609.587396153749337701.levitte@openssl.org>

In message <20180430131000.GA25216 at roeckx.be> on Mon, 30 Apr 2018 15:10:01 +0200, Kurt Roeckx <kurt at roeckx.be> said:

kurt> The comment about not hashing it is if you want to use the tool to
kurt> do entropy estimation. Hashing it will not increase the entropy,
kurt> but the estimation will be totally wrong.
kurt> 
kurt> Passing the hashed data to the drbg as entropy input is fine if
kurt> you already know how much entropy that it contains.

Thanks, that's what I suspected.  Ok, on to the next step

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Mon Apr 30 14:49:08 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 30 Apr 2018 16:49:08 +0200 (CEST)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180430.152609.587396153749337701.levitte@openssl.org>
References: <20180430.144253.1714680705314385876.levitte@openssl.org>
 <20180430131000.GA25216@roeckx.be>
 <20180430.152609.587396153749337701.levitte@openssl.org>
Message-ID: <20180430.164908.1424770216194967097.levitte@openssl.org>

In message <20180430.152609.587396153749337701.levitte at openssl.org> on Mon, 30 Apr 2018 15:26:09 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:

levitte> In message <20180430131000.GA25216 at roeckx.be> on Mon, 30 Apr 2018 15:10:01 +0200, Kurt Roeckx <kurt at roeckx.be> said:
levitte> 
levitte> kurt> The comment about not hashing it is if you want to use the tool to
levitte> kurt> do entropy estimation. Hashing it will not increase the entropy,
levitte> kurt> but the estimation will be totally wrong.
levitte> kurt> 
levitte> kurt> Passing the hashed data to the drbg as entropy input is fine if
levitte> kurt> you already know how much entropy that it contains.
levitte> 
levitte> Thanks, that's what I suspected.  Ok, on to the next step

Not done running, but does show some promise...

    : ; ./a.out ../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin  8 -v
    Opening file: ../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin
    
    Running non-IID tests...
    
    Entropic statistic estimates:
    Most Common Value Estimate = 0.975224
    Collision Test Estimate = 0.902997
    Markov Test Estimate = 0.410808
    Compression Test Estimate = 0.811274

I assume that estimate is per "word" (i.e. per 8 bits of data in this
case).

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Mon Apr 30 16:00:20 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 30 Apr 2018 18:00:20 +0200 (CEST)
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180430.164908.1424770216194967097.levitte@openssl.org>
References: <20180430131000.GA25216@roeckx.be>
 <20180430.152609.587396153749337701.levitte@openssl.org>
 <20180430.164908.1424770216194967097.levitte@openssl.org>
Message-ID: <20180430.180020.1402330384104485085.levitte@openssl.org>

In message <20180430.164908.1424770216194967097.levitte at openssl.org> on Mon, 30 Apr 2018 16:49:08 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:

levitte> In message <20180430.152609.587396153749337701.levitte at openssl.org> on Mon, 30 Apr 2018 15:26:09 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:
levitte> 
levitte> levitte> In message <20180430131000.GA25216 at roeckx.be> on Mon, 30 Apr 2018 15:10:01 +0200, Kurt Roeckx <kurt at roeckx.be> said:
levitte> levitte> 
levitte> levitte> kurt> The comment about not hashing it is if you want to use the tool to
levitte> levitte> kurt> do entropy estimation. Hashing it will not increase the entropy,
levitte> levitte> kurt> but the estimation will be totally wrong.
levitte> levitte> kurt> 
levitte> levitte> kurt> Passing the hashed data to the drbg as entropy input is fine if
levitte> levitte> kurt> you already know how much entropy that it contains.
levitte> levitte> 
levitte> levitte> Thanks, that's what I suspected.  Ok, on to the next step
levitte> 
levitte> Not done running, but does show some promise...
levitte> 
levitte>     : ; ./a.out ../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin  8 -v
levitte>     Opening file: ../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin
levitte>     
levitte>     Running non-IID tests...
levitte>     
levitte>     Entropic statistic estimates:
levitte>     Most Common Value Estimate = 0.975224
levitte>     Collision Test Estimate = 0.902997
levitte>     Markov Test Estimate = 0.410808
levitte>     Compression Test Estimate = 0.811274
levitte> 
levitte> I assume that estimate is per "word" (i.e. per 8 bits of data in this
levitte> case).

Ok, done running...  suffice to say, the first tests left me ever so
hopeful...

    : ; ./a.out ../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin  8 -v
    Opening file: ../../../levitte/vms-experiments/entropy-gathering/entropy-stats.bin
    
    Running non-IID tests...
    
    Entropic statistic estimates:
    Most Common Value Estimate = 0.975224
    Collision Test Estimate = 0.902997
    Markov Test Estimate = 0.410808
    Compression Test Estimate = 0.811274
    t-Tuple Test Estimate = 0.0818796
    Longest Reapeated Substring Test Estimate = 0.0818772
    
    Predictor estimates:
    Multi Most Common in Window (MultiMCW) Test: 100% complete
    	Correct: 507351
    	P_avg (global): 0.508671
    	P_run (local): 0.587891
    Multi Most Common in Window (Multi MCW) Test = 0.76638
    Lag Test: 100% complete
    	Correct: 269907
    	P_avg (global): 0.271051
    	P_run (local): 0.347168
    Lag Prediction Test = 1.52629
    MultiMMC Test: 100% complete
    	Correct: 11700
    	P_avg (global): 0.011977
    	P_run (local): 0.444824
    Multi Markov Model with Counting (MultiMMC) Prediction Test = 1.16869
    LZ78Y Test: 99% complete
    	Correct: 572107
    	P_avg (global): 0.573391
    	P_run (local): 0.615723
    LZ78Y Prediction Test = 0.699647
    Min Entropy: 0.0818772

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?
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...

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kurt at roeckx.be  Mon Apr 30 16:22:09 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 30 Apr 2018 18:22:09 +0200
Subject: [openssl-project] Entropy seeding the DRBG
In-Reply-To: <20180430.180020.1402330384104485085.levitte@openssl.org>
References: <20180430131000.GA25216@roeckx.be>
 <20180430.152609.587396153749337701.levitte@openssl.org>
 <20180430.164908.1424770216194967097.levitte@openssl.org>
 <20180430.180020.1402330384104485085.levitte@openssl.org>
Message-ID: <20180430162209.GA4439@roeckx.be>

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


From matt at openssl.org  Mon Apr 30 19:02:16 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 30 Apr 2018 20:02:16 +0100
Subject: [openssl-project] Freezing the repo
Message-ID: <068239e0-7926-d877-6be5-98dfc5dbf737@openssl.org>

Please could someone freeze the repo for me for tomorrow's release:

$ ssh openssl-git at git.openssl.org freeze openssl matt


Thanks

Matt

From rsalz at akamai.com  Mon Apr 30 19:04:34 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 30 Apr 2018 19:04:34 +0000
Subject: [openssl-project] Freezing the repo
In-Reply-To: <068239e0-7926-d877-6be5-98dfc5dbf737@openssl.org>
References: <068239e0-7926-d877-6be5-98dfc5dbf737@openssl.org>
Message-ID: <B7648573-E8AC-4D47-8662-6D3B0633FA5F@akamai.com>

Done.

?On 4/30/18, 3:02 PM, "Matt Caswell" <matt at openssl.org> wrote:

    Please could someone freeze the repo for me for tomorrow's release:
    
    $ ssh openssl-git at git.openssl.org freeze openssl matt
    
    
    Thanks
    
    Matt
    _______________________________________________
    openssl-project mailing list
    openssl-project at openssl.org
    https://mta.openssl.org/mailman/listinfo/openssl-project
    


From matt at openssl.org  Mon Apr 30 19:05:03 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 30 Apr 2018 20:05:03 +0100
Subject: [openssl-project] Beta release on Tuesday
In-Reply-To: <739E4C99-8D3D-4B45-9D05-5836C431D24C@akamai.com>
References: <8b047c59-1c55-6dff-06b4-1bc972bf1b33@openssl.org>
 <739E4C99-8D3D-4B45-9D05-5836C431D24C@akamai.com>
Message-ID: <917b896f-e26c-30c1-82eb-777d88a1792d@openssl.org>



On 27/04/18 12:12, Salz, Rich wrote:
>>    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.

Nobody else has stepped forward. Are you still available for this?

I would normally start around 12.00 UTC, but could push it a bit later
if it works better for you.

Matt


From rsalz at akamai.com  Mon Apr 30 19:07:00 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 30 Apr 2018 19:07:00 +0000
Subject: [openssl-project] Beta release on Tuesday
In-Reply-To: <917b896f-e26c-30c1-82eb-777d88a1792d@openssl.org>
References: <8b047c59-1c55-6dff-06b4-1bc972bf1b33@openssl.org>
 <739E4C99-8D3D-4B45-9D05-5836C431D24C@akamai.com>
 <917b896f-e26c-30c1-82eb-777d88a1792d@openssl.org>
Message-ID: <8C2129D3-8EF7-47EC-9005-CEAF3D40D994@akamai.com>

>    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.


From matt at openssl.org  Mon Apr 30 19:34:11 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 30 Apr 2018 20:34:11 +0100
Subject: [openssl-project] Beta release on Tuesday
In-Reply-To: <8C2129D3-8EF7-47EC-9005-CEAF3D40D994@akamai.com>
References: <8b047c59-1c55-6dff-06b4-1bc972bf1b33@openssl.org>
 <739E4C99-8D3D-4B45-9D05-5836C431D24C@akamai.com>
 <917b896f-e26c-30c1-82eb-777d88a1792d@openssl.org>
 <8C2129D3-8EF7-47EC-9005-CEAF3D40D994@akamai.com>
Message-ID: <974834f1-70fc-3e0b-dbf1-576f570e3d0d@openssl.org>



On 30/04/18 20:07, Salz, Rich wrote:
>>    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.
> 

Ok, lets make it 13.00 UTC.

Matt


From rsalz at akamai.com  Mon Apr 30 20:00:59 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 30 Apr 2018 20:00:59 +0000
Subject: [openssl-project] Beta release on Tuesday
In-Reply-To: <974834f1-70fc-3e0b-dbf1-576f570e3d0d@openssl.org>
References: <8b047c59-1c55-6dff-06b4-1bc972bf1b33@openssl.org>
 <739E4C99-8D3D-4B45-9D05-5836C431D24C@akamai.com>
 <917b896f-e26c-30c1-82eb-777d88a1792d@openssl.org>
 <8C2129D3-8EF7-47EC-9005-CEAF3D40D994@akamai.com>
 <974834f1-70fc-3e0b-dbf1-576f570e3d0d@openssl.org>
Message-ID: <6B3638A7-5614-48E5-BB56-EC930A848073@akamai.com>

    >>    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.
    > 
    
    Ok, lets make it 13.00 UTC.

Gaah, forgot about daylight savings.  12.00 UTC is 8am my time.  Keep it at 12.00 UTC



From matt at openssl.org  Mon Apr 30 21:48:13 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 30 Apr 2018 22:48:13 +0100
Subject: [openssl-project] Beta release on Tuesday
In-Reply-To: <6B3638A7-5614-48E5-BB56-EC930A848073@akamai.com>
References: <8b047c59-1c55-6dff-06b4-1bc972bf1b33@openssl.org>
 <739E4C99-8D3D-4B45-9D05-5836C431D24C@akamai.com>
 <917b896f-e26c-30c1-82eb-777d88a1792d@openssl.org>
 <8C2129D3-8EF7-47EC-9005-CEAF3D40D994@akamai.com>
 <974834f1-70fc-3e0b-dbf1-576f570e3d0d@openssl.org>
 <6B3638A7-5614-48E5-BB56-EC930A848073@akamai.com>
Message-ID: <83a87950-a065-cc2b-5252-c518835fb974@openssl.org>



On 30/04/18 21:00, Salz, Rich wrote:
>     >>    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.
>     > 
>     
>     Ok, lets make it 13.00 UTC.
> 
> Gaah, forgot about daylight savings.  12.00 UTC is 8am my time.  Keep it at 12.00 UTC

Ok - 12.00UTC it is.

Matt


> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>