From rsalz at akamai.com  Mon Jan  1 16:25:48 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 1 Jan 2018 16:25:48 +0000
Subject: [openssl-dev] Is X509_free(NULL) ok?
In-Reply-To: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
References: <82579724-69e3-df25-cf79-21bafbb7d44c@yahoo.com>
Message-ID: <19A0CAC7-6AD3-43C3-9091-B3E4445E7E20@akamai.com>

Yes you can do so.  It is documented in most of the manpages, and in 1.1.0 and later it should be in all of them.

On 1/1/18, 11:19 AM, "Ray Satiro via openssl-dev" <openssl-dev at openssl.org> wrote:

    I'm trying to figure out whether it's supported to call X509_free(NULL)
    in 1.0.2 and beyond. It's not documented what action occurs when the
    pointer is null. Also generally speaking is it supported to call openssl
    free functions with null pointers?
    
    
    -- 
    openssl-dev mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
    


From mcr at sandelman.ca  Wed Jan  3 23:34:35 2018
From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 03 Jan 2018 18:34:35 -0500
Subject: [openssl-dev] weird loop in s3_lib.c
Message-ID: <27664.1515022475@obiwan.sandelman.ca>


in
        const SSL_CIPHER *ssl3_choose_cipher(SSL *s, STACK_OF(SSL_CIPHER) *clnt,
                                     STACK_OF(SSL_CIPHER) *srvr)


we have:

    for (i = 0; i < sk_SSL_CIPHER_num(prio); i++) {
        c = sk_SSL_CIPHER_value(prio, i);
        ...

            if (!ok)
                continue;
        }


The if (!ok) continue;
is just a no-op.  Maybe it said at some point:
      "if(ok) break;"

which would have an affect, or maybe there was some code after it that was
removed.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180103/e8bf5c70/attachment.sig>

From mcr at sandelman.ca  Wed Jan  3 23:38:15 2018
From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 03 Jan 2018 18:38:15 -0500
Subject: [openssl-dev] weird loop in s3_lib.c
In-Reply-To: <27664.1515022475@obiwan.sandelman.ca>
References: <27664.1515022475@obiwan.sandelman.ca>
Message-ID: <28487.1515022695@obiwan.sandelman.ca>


Michael Richardson <mcr at sandelman.ca> wrote:
    > in
    > const SSL_CIPHER *ssl3_choose_cipher(SSL *s, STACK_OF(SSL_CIPHER) *clnt,
    > STACK_OF(SSL_CIPHER) *srvr)

never mind.
I mis-read the brackets.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180103/68965ab0/attachment.sig>

From murugesh.pitchaiah at gmail.com  Fri Jan  5 12:38:43 2018
From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah)
Date: Fri, 5 Jan 2018 18:08:43 +0530
Subject: [openssl-dev] FIPS_mode_set - failed - SSLEAY_RAND_BYTES:PRNG not
	seeded
Message-ID: <CAOu9RAcWrs6w+9Erih7m22OwrVGGrK1wc9rgt-LQvG=4KS+Xfw@mail.gmail.com>

Hi All,

Need your inputs on below issue:

When I try to set the FIPS mode, seeing below error and failure intermittently:

Error: FIPS_mode_set(1) failed. Reason: error:24064064:random number
generator:SSLEAY_RAND_BYTES:PRNG not seeded

I am using following versions:
openssl-1.0.2k
openssl-fips-ecp-2.0.16 in canister model.

Please share if this is known issue and any fix available for the same.

Thanks,
Murugesh P.

From wbathurs at gmail.com  Fri Jan  5 18:52:01 2018
From: wbathurs at gmail.com (William Bathurst)
Date: Fri, 5 Jan 2018 10:52:01 -0800
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
Message-ID: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>

Hello All,

We have open sourced our work in regards to integrating the Speck Cipher 
with OpenSSL. Basic information about this cipher can be found here.

https://en.wikipedia.org/wiki/Speck_(cipher) 
<https://en.wikipedia.org/wiki/Speck_%28cipher%29>

SPECK is a lightweight block ciphers each of which comes in a variety of 
widths and key sizes and is targeted towards resource constrained 
devices and environments. This implementation is currently implemented 
using the 128 and 256 block sizes.

We are currently modifying the source from Apache to OpenSSL open source 
licensing for the Speck/OpenSSL integration. Related repositories such 
as the cipher itself will remain under the Apache license. We would love 
input on the following items:

1) Community interest in such a lightweight cipher.
2) Committers willing to help on the code for improvements.
3) Information on how to make this available as a patch.

We have currently integrated Speck with OpenSSL 1.1. We also have an 
Speck Client software available for people who wish to test this 
software. Future ports will be to mbedTLS.

We have listed making it available as an issue:

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

OpenSSL/Speck Integration open source repositories:

https://github.com/m2mi/openssl_speck
https://github.com/m2mi/open_speck

Feel free to contact to to discuss the cipher and uses.

With Regards,
Bill


From mcr at sandelman.ca  Fri Jan  5 19:18:21 2018
From: mcr at sandelman.ca (Michael Richardson)
Date: Fri, 05 Jan 2018 14:18:21 -0500
Subject: [openssl-dev] DTLS "accept" functionality
Message-ID: <24932.1515179901@obiwan.sandelman.ca>


I have been working since mid-November in my "copious spare time" to bring
DTLS support into ruby-openssl in order to bring DTLS into the Rails "David"
CoAP server.

DTLS_listen() seems entirely focused on single-use situations like in RTP,
where only a single connection (single DTLS session) is expected. If used
in CoAP situation, there are a number of race conditions that make it
hard to use correctly.   I wrote another email about that, which I think did
not get to the list, which I can resend.

I have preserved DLTSv1_listen() functionality, refactoring most of it
into DTLSv1_anwerHello(), and then adding DTLSv1_accept() on top of it.

Unfortunately I was also forced to delve into dgram_bss.c in order to bring
some additional information out; stuff which is rather OS dependant for IPv4,
and which perhaps would be better done in the application somehow.

I'm looking for advice.

Also, I found it difficult to find the right incantation to get a static
build; I noticed finally that my test/* programs were linking against the
libssl that was in my /lib, rather than the code I was testing.  I suggest
that this be captured into a ./Configure option.  I used:

     ./Configure no-shared --debug linux-x86_64

"no-dso" seemed like it ought to help, but it made things worse...

I hope that I added the new exposed symbols correctly.
I have yet to validate the complete david/coap/ruby-openssl/dtls
functionality, but I wanted to post this sooner for review.


https://github.com/openssl/openssl/pull/5024 says:

This patch refactors the DTLSv1_listen() to create an alternative API that is
called DTLSv1_accept().

DTLSv1_accept() is useable by programs that need to treat DTLS interfaces in
a way similar to TCP: new connections must be accepted, and new sockets
created.

There are a number of changes included here:

1. dgram_write() and dgram_read() now use sendmsg(2) and recvmsg(2) in order to set and collect the local address used in the datagram.  This allows a socket to bound to ::, while still sending traffic correctly from the address that the other peer used. The IPv6 version of this code is according to rfc3542 API, but the IPv4 of the code is Linux specific and needs to be either abstracted and translated for *BSD and Windows, or IPv6 mapped IPv4 sockets could be used.
2. a new BIO control SET_ADDR and GET_ADDR are added, and if the address is not set then it pulls it out of the socket using getsockname(2).
3. DTLSv1_accept() accepts a second SSL* on which new connections are setup. A new socket is set up using the addresses from the received message and it is inserted into the BIO. There is a race condition during setup which turned out to be unavoidable: between the bind(2) and the connect(2), the new socket could have the same address as the "listen" socket, and additional hello packets could arrive on the wrong socket.  Such packets will hopefully be dropped as garbage. It was thought that connect(2) could be called before bind(2), but that seems to cause the kernel to allocate a local address for the new socket (a random port), which the subsequent bind(2) can not seem to change.
4. the use of POSIX socket APIs inside this code is likely inappropriate and this routine should be split up in some better way so that socket activities can be done by the application, using the correct abstractions for the OS.
5. a new test case dtlsaccepttest was created.  It uses fork() and also calls system() on "openssl s_client". Probably it should just call code internally, but apps/* is not in a library form that can be used. Perhaps this use is acceptable.  Other test functions just use canned packets in/out, but since this is testing the creation/adaption of socket code, real sockets would seem to be necessary.  Probably this test case should be disabled on non-Unix platforms.
6. routines BIO_ADDR_sockaddr and BIO_ADDR_sockaddr_size exposed from libcrypto to libssl.  There might be a better way to do this, perhaps a BIO_CTRL would be better?



--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180105/b26c3f33/attachment.sig>

From hanno at hboeck.de  Fri Jan  5 19:40:40 2018
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Fri, 5 Jan 2018 20:40:40 +0100
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
Message-ID: <20180105204040.5b2f5747@pc1>

On Fri, 5 Jan 2018 10:52:01 -0800
William Bathurst <wbathurs at gmail.com> wrote:

> 1) Community interest in such a lightweight cipher.

I think there's a shifting view that "more is not always good" in
crypto. OpenSSL has added features in the past "just because" and it
was often a bad decision.

Therefore I'd generally oppose adding ciphers without a clear usecase,
as increased code complexity has a cost.
So I think questions that should be answered:
What's the usecase for speck in OpenSSL? Are there plans to use it in
TLS? If yes why? By whom? What advantages does it have over existing
ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)


Also just for completeness, as some may not be aware: There are some
concerns about Speck due to its origin (aka the NSA). I don't think
that is a reason to dismiss a cipher right away, what I'd find more
concerning is that from what I observed there hasn't been a lot of
research about speck.

-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

From dkg at fifthhorseman.net  Fri Jan  5 19:33:59 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 05 Jan 2018 14:33:59 -0500
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
Message-ID: <87o9m89k2g.fsf@fifthhorseman.net>

Hi Bill--

On Fri 2018-01-05 10:52:01 -0800, William Bathurst wrote:

> We have open sourced our work in regards to integrating the Speck Cipher 
> with OpenSSL. Basic information about this cipher can be found here.
>
> https://en.wikipedia.org/wiki/Speck_(cipher) 
> <https://en.wikipedia.org/wiki/Speck_%28cipher%29>
>
> SPECK is a lightweight block ciphers each of which comes in a variety of 
> widths and key sizes and is targeted towards resource constrained 
> devices and environments. This implementation is currently implemented 
> using the 128 and 256 block sizes.

Thanks for your work on this, and for reporting on it here.  Out of
curiosity, who is the "We" involved here?  The changeset history
appears to be a bit ambivalent about the authorship, based on edits to
the README itself:

  https://github.com/m2mi/openssl_speck/commit/4a67a5644ff5c56956063d858033585f57686d1e
  https://github.com/m2mi/openssl_speck/commit/8d619beffa3bd1c221fc6a7946b9aa7a00774019

> 1) Community interest in such a lightweight cipher.

I'm not convinced that the OpenSSL project should encourage the adoption
of SPECK, given the general level of distrust around the algorithm:

  https://www.schneier.com/blog/archives/2017/09/iso_rejects_nsa.html

My understanding is that the algorithm designers and primary advocates
have not been particularly forthcoming with their design goals, and
their reputation is mixed, at best.

Regards,

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180105/7dab5b75/attachment.sig>

From wbathurs at gmail.com  Mon Jan  8 21:10:07 2018
From: wbathurs at gmail.com (William Bathurst)
Date: Mon, 8 Jan 2018 13:10:07 -0800
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <20180105204040.5b2f5747@pc1>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <20180105204040.5b2f5747@pc1>
Message-ID: <fc576225-4efc-5d85-aaf0-b0ef92062519@gmail.com>

Hi Hanno/all,

I can understand your view that "more is not always good" in crypto. The 
reasoning behind the offering can be found in the following whitepaper:

https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf

I will summarize in a different way though. We wish to offer an 
optimized lightweight TLS for IoT. A majority of devices found in IoT 
are resource constrained, for example a device CPU may only have 32K of 
RAM. Therefore security is an afterthought by developers. For some only 
AES 128 is available and they wish to use 256 bit encryption. Then Speck 
256 would be an option because it has better performance and provides 
sufficient security.

Based on the above scenario you can likely see why we are interested in 
OpenSSL. First, OpenSSL can be used for terminating lightweight TLS 
connections near the edge, and then forwarding using commonly used ciphers.

[IoT Device] -----TLS/Speck---->[IoT Gateway]-----TLS----> [Services]

Also, we are interested in using OpenSSL libraries at the edge for 
client creation. One thing we would like to do is provide instructions 
for an highly optimized build of OpenSSL that can be used for contrained 
devices.

I think demand will eventually grow because there is an initiative by 
the US government to improve IoT Security and Speck is being developed 
and proposed as a standard within the government. Therefore, I see users 
who wish to play in this space would be interested in a version where 
Speck could be used in OpenSSL.

It is my hope to accomplish the following:

[1] Make Speck available via Open Source, this could be as an option or 
as a patch in OpenSSL.
[2] If we make it available as a patch, is there a place where we would 
announce/make it known that it is available?

We are also looking at open-sourcing the client side code. This would be 
used to create light-weight clients that use Speck and currently we also 
build basic OAuth capability on top of it.

Thanks for your input!

Bill

On 1/5/2018 11:40 AM, Hanno B?ck wrote:
> On Fri, 5 Jan 2018 10:52:01 -0800
> William Bathurst <wbathurs at gmail.com> wrote:
>
>> 1) Community interest in such a lightweight cipher.
> I think there's a shifting view that "more is not always good" in
> crypto. OpenSSL has added features in the past "just because" and it
> was often a bad decision.
>
> Therefore I'd generally oppose adding ciphers without a clear usecase,
> as increased code complexity has a cost.
> So I think questions that should be answered:
> What's the usecase for speck in OpenSSL? Are there plans to use it in
> TLS? If yes why? By whom? What advantages does it have over existing
> ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)
>
>
> Also just for completeness, as some may not be aware: There are some
> concerns about Speck due to its origin (aka the NSA). I don't think
> that is a reason to dismiss a cipher right away, what I'd find more
> concerning is that from what I observed there hasn't been a lot of
> research about speck.
>


From bkaduk at akamai.com  Mon Jan  8 21:31:48 2018
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 8 Jan 2018 15:31:48 -0600
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <fc576225-4efc-5d85-aaf0-b0ef92062519@gmail.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <20180105204040.5b2f5747@pc1>
 <fc576225-4efc-5d85-aaf0-b0ef92062519@gmail.com>
Message-ID: <09e2b9a3-4d4d-f789-14f8-0ad708531370@akamai.com>

On 01/08/2018 03:10 PM, William Bathurst wrote:
> Hi Hanno/all,
>
> I can understand your view that "more is not always good" in crypto.
> The reasoning behind the offering can be found in the following
> whitepaper:
>
> https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf
>
>
> I will summarize in a different way though. We wish to offer an
> optimized lightweight TLS for IoT. A majority of devices found in IoT
> are resource constrained, for example a device CPU may only have 32K
> of RAM. Therefore security is an afterthought by developers. For some
> only AES 128 is available and they wish to use 256 bit encryption.
> Then Speck 256 would be an option because it has better performance
> and provides sufficient security.
>
> Based on the above scenario you can likely see why we are interested
> in OpenSSL. First, OpenSSL can be used for terminating lightweight TLS
> connections near the edge, and then forwarding using commonly used
> ciphers.
>
> [IoT Device] -----TLS/Speck---->[IoT Gateway]-----TLS----> [Services]
>
> Also, we are interested in using OpenSSL libraries at the edge for
> client creation. One thing we would like to do is provide instructions
> for an highly optimized build of OpenSSL that can be used for
> contrained devices.
>
> I think demand will eventually grow because there is an initiative by
> the US government to improve IoT Security and Speck is being developed
> and proposed as a standard within the government. Therefore, I see
> users who wish to play in this space would be interested in a version
> where Speck could be used in OpenSSL.
>
> It is my hope to accomplish the following:
>
> [1] Make Speck available via Open Source, this could be as an option
> or as a patch in OpenSSL.
> [2] If we make it available as a patch, is there a place where we
> would announce/make it known that it is available?
>
> We are also looking at open-sourcing the client side code. This would
> be used to create light-weight clients that use Speck and currently we
> also build basic OAuth capability on top of it.
>

Interestingly, the IETF ACE (Authentication and Authorization in
Constrained Environments) is chartered to look at this space (crypto for
constrained systems/IoT), and is aiming towards something roughly
OAuth-shaped, but there has not really been any interest in Speck
expressed that I've seen.? So, is this work happening someplace else, or
is there not actually demand for it?

-Ben

> Thanks for your input!
>
> Bill
>
> On 1/5/2018 11:40 AM, Hanno B?ck wrote:
>> On Fri, 5 Jan 2018 10:52:01 -0800
>> William Bathurst <wbathurs at gmail.com> wrote:
>>
>>> 1) Community interest in such a lightweight cipher.
>> I think there's a shifting view that "more is not always good" in
>> crypto. OpenSSL has added features in the past "just because" and it
>> was often a bad decision.
>>
>> Therefore I'd generally oppose adding ciphers without a clear usecase,
>> as increased code complexity has a cost.
>> So I think questions that should be answered:
>> What's the usecase for speck in OpenSSL? Are there plans to use it in
>> TLS? If yes why? By whom? What advantages does it have over existing
>> ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)
>>
>>
>> Also just for completeness, as some may not be aware: There are some
>> concerns about Speck due to its origin (aka the NSA). I don't think
>> that is a reason to dismiss a cipher right away, what I'd find more
>> concerning is that from what I observed there hasn't been a lot of
>> research about speck.
>>
>


From misaki.miyashita at oracle.com  Mon Jan  8 22:46:15 2018
From: misaki.miyashita at oracle.com (Misaki Miyashita)
Date: Mon, 8 Jan 2018 16:46:15 -0600
Subject: [openssl-dev] [openssl-users] Failed to access LDAP server when
 a valid certificate is at <hash>.1+
In-Reply-To: <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org>
References: <59EB65C1.80100@oracle.com>
 <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org>
Message-ID: <5A53F4B7.8030401@oracle.com>

(switching the alias to openssl-dev at openssl.org)

I would like to suggest the following fix so that a valid certificate at 
<hash>.x can be recognized during the cert validation even when <hash>.0 
is linking to a bad/expired certificate.  This may not be the most 
elegant solution, but it is a minimal change with low impact to the rest 
of the code.

Could I possibly get a review on the change? and possibly be considered 
to be integrated to the upstream?
(This is for the 1.0.1 branch)

Thanks in advance.

-- misaki


--- a/crypto/x509/x509_vfy.c    2017-11-02 07:32:58.000000000 -0700
+++ b/crypto/x509/x509_vfy.c    2017-12-11 12:37:55.591835780 -0800
@@ -185,6 +185,39 @@
      return xtmp;
  }

+/*
+ * Look through the trust store setup by get_issuer() and
+ * return the certificate which matches the server cert 'x'
+ * via 'xtmp'.
+ */
+static int X509_get_cert(X509 **xtmp, X509_STORE_CTX *ctx, X509 *x)
+{
+    X509_OBJECT    *tmp;
+    int            i;
+    int            ret = 0;
+
+    CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
+    for (i = 0; i < sk_X509_OBJECT_num(ctx->ctx->objs); i++) {
+        tmp = sk_X509_OBJECT_value(ctx->ctx->objs, i);
+        if (tmp == NULL) {
+            goto exit;
+        }
+        if (X509_cmp(tmp->data.x509, x) == 0) {
+            /*
+             * Found the cert in the trust store which matches the
+             * server cert.  Increment the ref count and return.
+             */
+            X509_OBJECT_up_ref_count(tmp);
+            *xtmp = tmp->data.x509;
+            ret = 1;
+            goto exit;
+        }
+    }
+exit:
+    CRYPTO_w_unlock(CRYPTO_LOCK_X509_STORE);
+    return ret;
+}
+
  int X509_verify_cert(X509_STORE_CTX *ctx)
  {
      X509 *x, *xtmp, *xtmp2, *chain_ss = NULL;
@@ -316,9 +350,13 @@
                   * We have a single self signed certificate: see if we can
                   * find it in the store. We must have an exact match 
to avoid
                   * possible impersonation.
+                 * get_issuer() sets up the trust store for the subject and
+                 * returns the first cert via 'xtmp'. The first cert in the
+                 * trust store may not be the certificate that we are 
interested
+                 * in. Look through the trust store to see there is an 
exact match.
                   */
                  ok = ctx->get_issuer(&xtmp, ctx, x);
-                if ((ok <= 0) || X509_cmp(x, xtmp)) {
+                if ((ok <= 0) || (X509_get_cert(&xtmp, ctx, x) != 1)) {
                      ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
                      ctx->current_cert = x;
                      ctx->error_depth = i - 1;


On 10/21/17 03:21 PM, Viktor Dukhovni wrote:
>
> On Oct 21, 2017, at 11:20 AM, Misaki Miyashita <misaki.miyashita at oracle.com> wrote:
>
>> We encountered a problem using OpenLDAP with OpenSSL when there were more than one certificate with the same subject.
>>
>> Does OpenSSL stop searching for a valid certificate when it finds a certificate with matching DN?
> Yes, when a matching issuer is found in the trust store, but is expired
> no alternative certificates will be tested.  You need to remove outdated
> issuer certificates from your trust store before they expire.
>


From paul.dale at oracle.com  Mon Jan  8 21:58:59 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Mon, 8 Jan 2018 13:58:59 -0800 (PST)
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <fc576225-4efc-5d85-aaf0-b0ef92062519@gmail.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <20180105204040.5b2f5747@pc1>
 <fc576225-4efc-5d85-aaf0-b0ef92062519@gmail.com>
Message-ID: <a37c4b30-0f9d-4894-ad63-35b971ffe368@default>

I'm wondering if one of the more specialised embedded cryptographic toolkits mightn't be a better option for your lightweight IoT TLS stack.  There is a wide choice available: CycloneSSL, ECT, Fusion, MatrixSSL, mbedTLS, NanoSSL, SharkSSL, WolfSSL, uC/SSL and many others.  All of them claim to be the smallest, fastest and most feature laden :)  To sell to the US government,  your first selection criteria should be "does the toolkit have a current FIPS validation?"  From memory this means: ECT, nanoSSL or WolfSSL.

The more comprehensive toolkits (OpenSSL, NSS, GNU TLS) are less suitable for embedded applications, especially tightly resource constrained ones.  It is possible to cut OpenSSL down in size but it will never compete with the designed for embedded toolkits.  Plus, the FIPS module is fixed and cannot be shrunk.

The current OpenSSL FIPS validation only applies to 1.0.2 builds currently.  FIPS is on the project plan for 1.1 but it isn't available at the moment.  The US government is forbidden to purchase any product that contains cryptographic operations unless the product has a FIPS validation.  No FIPS, no sale.


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

-----Original Message-----
From: William Bathurst [mailto:wbathurs at gmail.com] 
Sent: Tuesday, 9 January 2018 7:10 AM
To: openssl-dev at openssl.org
Cc: Llamoureux at gmail.com
Subject: Re: [openssl-dev] Speck Cipher Integration with OpenSSL

Hi Hanno/all,

I can understand your view that "more is not always good" in crypto. The reasoning behind the offering can be found in the following whitepaper:

https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf

I will summarize in a different way though. We wish to offer an optimized lightweight TLS for IoT. A majority of devices found in IoT are resource constrained, for example a device CPU may only have 32K of RAM. Therefore security is an afterthought by developers. For some only AES 128 is available and they wish to use 256 bit encryption. Then Speck
256 would be an option because it has better performance and provides sufficient security.

Based on the above scenario you can likely see why we are interested in OpenSSL. First, OpenSSL can be used for terminating lightweight TLS connections near the edge, and then forwarding using commonly used ciphers.

[IoT Device] -----TLS/Speck---->[IoT Gateway]-----TLS----> [Services]

Also, we are interested in using OpenSSL libraries at the edge for client creation. One thing we would like to do is provide instructions for an highly optimized build of OpenSSL that can be used for contrained devices.

I think demand will eventually grow because there is an initiative by the US government to improve IoT Security and Speck is being developed and proposed as a standard within the government. Therefore, I see users who wish to play in this space would be interested in a version where Speck could be used in OpenSSL.

It is my hope to accomplish the following:

[1] Make Speck available via Open Source, this could be as an option or as a patch in OpenSSL.
[2] If we make it available as a patch, is there a place where we would announce/make it known that it is available?

We are also looking at open-sourcing the client side code. This would be used to create light-weight clients that use Speck and currently we also build basic OAuth capability on top of it.

Thanks for your input!

Bill

On 1/5/2018 11:40 AM, Hanno B?ck wrote:
> On Fri, 5 Jan 2018 10:52:01 -0800
> William Bathurst <wbathurs at gmail.com> wrote:
>
>> 1) Community interest in such a lightweight cipher.
> I think there's a shifting view that "more is not always good" in 
> crypto. OpenSSL has added features in the past "just because" and it 
> was often a bad decision.
>
> Therefore I'd generally oppose adding ciphers without a clear usecase, 
> as increased code complexity has a cost.
> So I think questions that should be answered:
> What's the usecase for speck in OpenSSL? Are there plans to use it in 
> TLS? If yes why? By whom? What advantages does it have over existing 
> ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)
>
>
> Also just for completeness, as some may not be aware: There are some 
> concerns about Speck due to its origin (aka the NSA). I don't think 
> that is a reason to dismiss a cipher right away, what I'd find more 
> concerning is that from what I observed there hasn't been a lot of 
> research about speck.
>

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From levitte at openssl.org  Tue Jan  9 02:58:17 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 03:58:17 +0100 (CET)
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <a37c4b30-0f9d-4894-ad63-35b971ffe368@default>
References: <20180105204040.5b2f5747@pc1>
 <fc576225-4efc-5d85-aaf0-b0ef92062519@gmail.com>
 <a37c4b30-0f9d-4894-ad63-35b971ffe368@default>
Message-ID: <20180109.035817.643451574880922174.levitte@openssl.org>

I'm not terribly savvy regarding IoT, but I imagine that they do talk
to something bigger.  A server end, perhaps?  What do we expect to run
on that end?  What happens, in that case, if SPECK makes its way into
the TLS cipher suites?  Would it be interesting to have OpenSSL
interop with such devices?

Note: I'm not terribly partial either way, just thought that we need
to look at it from a broader perspective...

Cheers,
Richard

In message <a37c4b30-0f9d-4894-ad63-35b971ffe368 at default> on Mon, 8 Jan 2018 13:58:59 -0800 (PST), Paul Dale <paul.dale at oracle.com> said:

paul.dale> I'm wondering if one of the more specialised embedded cryptographic toolkits mightn't be a better option for your lightweight IoT TLS stack.  There is a wide choice available: CycloneSSL, ECT, Fusion, MatrixSSL, mbedTLS, NanoSSL, SharkSSL, WolfSSL, uC/SSL and many others.  All of them claim to be the smallest, fastest and most feature laden :)  To sell to the US government,  your first selection criteria should be "does the toolkit have a current FIPS validation?"  From memory this means: ECT, nanoSSL or WolfSSL.
paul.dale> 
paul.dale> The more comprehensive toolkits (OpenSSL, NSS, GNU TLS) are less suitable for embedded applications, especially tightly resource constrained ones.  It is possible to cut OpenSSL down in size but it will never compete with the designed for embedded toolkits.  Plus, the FIPS module is fixed and cannot be shrunk.
paul.dale> 
paul.dale> The current OpenSSL FIPS validation only applies to 1.0.2 builds currently.  FIPS is on the project plan for 1.1 but it isn't available at the moment.  The US government is forbidden to purchase any product that contains cryptographic operations unless the product has a FIPS validation.  No FIPS, no sale.
paul.dale> 
paul.dale> 
paul.dale> Pauli
paul.dale> -- 
paul.dale> Oracle
paul.dale> Dr Paul Dale | Cryptographer | Network Security & Encryption 
paul.dale> Phone +61 7 3031 7217
paul.dale> Oracle Australia
paul.dale> 
paul.dale> -----Original Message-----
paul.dale> From: William Bathurst [mailto:wbathurs at gmail.com] 
paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM
paul.dale> To: openssl-dev at openssl.org
paul.dale> Cc: Llamoureux at gmail.com
paul.dale> Subject: Re: [openssl-dev] Speck Cipher Integration with OpenSSL
paul.dale> 
paul.dale> Hi Hanno/all,
paul.dale> 
paul.dale> I can understand your view that "more is not always good" in crypto. The reasoning behind the offering can be found in the following whitepaper:
paul.dale> 
paul.dale> https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf
paul.dale> 
paul.dale> I will summarize in a different way though. We wish to offer an optimized lightweight TLS for IoT. A majority of devices found in IoT are resource constrained, for example a device CPU may only have 32K of RAM. Therefore security is an afterthought by developers. For some only AES 128 is available and they wish to use 256 bit encryption. Then Speck
paul.dale> 256 would be an option because it has better performance and provides sufficient security.
paul.dale> 
paul.dale> Based on the above scenario you can likely see why we are interested in OpenSSL. First, OpenSSL can be used for terminating lightweight TLS connections near the edge, and then forwarding using commonly used ciphers.
paul.dale> 
paul.dale> [IoT Device] -----TLS/Speck---->[IoT Gateway]-----TLS----> [Services]
paul.dale> 
paul.dale> Also, we are interested in using OpenSSL libraries at the edge for client creation. One thing we would like to do is provide instructions for an highly optimized build of OpenSSL that can be used for contrained devices.
paul.dale> 
paul.dale> I think demand will eventually grow because there is an initiative by the US government to improve IoT Security and Speck is being developed and proposed as a standard within the government. Therefore, I see users who wish to play in this space would be interested in a version where Speck could be used in OpenSSL.
paul.dale> 
paul.dale> It is my hope to accomplish the following:
paul.dale> 
paul.dale> [1] Make Speck available via Open Source, this could be as an option or as a patch in OpenSSL.
paul.dale> [2] If we make it available as a patch, is there a place where we would announce/make it known that it is available?
paul.dale> 
paul.dale> We are also looking at open-sourcing the client side code. This would be used to create light-weight clients that use Speck and currently we also build basic OAuth capability on top of it.
paul.dale> 
paul.dale> Thanks for your input!
paul.dale> 
paul.dale> Bill
paul.dale> 
paul.dale> On 1/5/2018 11:40 AM, Hanno B?ck wrote:
paul.dale> > On Fri, 5 Jan 2018 10:52:01 -0800
paul.dale> > William Bathurst <wbathurs at gmail.com> wrote:
paul.dale> >
paul.dale> >> 1) Community interest in such a lightweight cipher.
paul.dale> > I think there's a shifting view that "more is not always good" in 
paul.dale> > crypto. OpenSSL has added features in the past "just because" and it 
paul.dale> > was often a bad decision.
paul.dale> >
paul.dale> > Therefore I'd generally oppose adding ciphers without a clear usecase, 
paul.dale> > as increased code complexity has a cost.
paul.dale> > So I think questions that should be answered:
paul.dale> > What's the usecase for speck in OpenSSL? Are there plans to use it in 
paul.dale> > TLS? If yes why? By whom? What advantages does it have over existing 
paul.dale> > ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)
paul.dale> >
paul.dale> >
paul.dale> > Also just for completeness, as some may not be aware: There are some 
paul.dale> > concerns about Speck due to its origin (aka the NSA). I don't think 
paul.dale> > that is a reason to dismiss a cipher right away, what I'd find more 
paul.dale> > concerning is that from what I observed there hasn't been a lot of 
paul.dale> > research about speck.
paul.dale> >
paul.dale> 
paul.dale> --
paul.dale> openssl-dev mailing list
paul.dale> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
paul.dale> -- 
paul.dale> openssl-dev mailing list
paul.dale> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From misaki.miyashita at oracle.com  Tue Jan  9 06:53:17 2018
From: misaki.miyashita at oracle.com (Misaki Miyashita)
Date: Tue, 9 Jan 2018 00:53:17 -0600
Subject: [openssl-dev] [openssl-users] Failed to access LDAP server when
 a valid certificate is at <hash>.1+
In-Reply-To: <5A53F4B7.8030401@oracle.com>
References: <59EB65C1.80100@oracle.com>
 <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org>
 <5A53F4B7.8030401@oracle.com>
Message-ID: <5A5466DD.3090402@oracle.com>



On 01/ 8/18 04:46 PM, Misaki Miyashita wrote:
> (switching the alias to openssl-dev at openssl.org)
>
> I would like to suggest the following fix so that a valid certificate 
> at <hash>.x can be recognized during the cert validation even when 
> <hash>.0 is linking to a bad/expired certificate.  This may not be the 
> most elegant solution, but it is a minimal change with low impact to 
> the rest of the code.
>
> Could I possibly get a review on the change? and possibly be 
> considered to be integrated to the upstream?
> (This is for the 1.0.1 branch)

Sorry, I meant to say it is for the 1.0.2 branch.

>
> Thanks in advance.
>
> -- misaki
>
>
> --- a/crypto/x509/x509_vfy.c    2017-11-02 07:32:58.000000000 -0700
> +++ b/crypto/x509/x509_vfy.c    2017-12-11 12:37:55.591835780 -0800
> @@ -185,6 +185,39 @@
>      return xtmp;
>  }
>
> +/*
> + * Look through the trust store setup by get_issuer() and
> + * return the certificate which matches the server cert 'x'
> + * via 'xtmp'.
> + */
> +static int X509_get_cert(X509 **xtmp, X509_STORE_CTX *ctx, X509 *x)
> +{
> +    X509_OBJECT    *tmp;
> +    int            i;
> +    int            ret = 0;
> +
> +    CRYPTO_w_lock(CRYPTO_LOCK_X509_STORE);
> +    for (i = 0; i < sk_X509_OBJECT_num(ctx->ctx->objs); i++) {
> +        tmp = sk_X509_OBJECT_value(ctx->ctx->objs, i);
> +        if (tmp == NULL) {
> +            goto exit;
> +        }
> +        if (X509_cmp(tmp->data.x509, x) == 0) {
> +            /*
> +             * Found the cert in the trust store which matches the
> +             * server cert.  Increment the ref count and return.
> +             */
> +            X509_OBJECT_up_ref_count(tmp);
> +            *xtmp = tmp->data.x509;
> +            ret = 1;
> +            goto exit;
> +        }
> +    }
> +exit:
> +    CRYPTO_w_unlock(CRYPTO_LOCK_X509_STORE);
> +    return ret;
> +}
> +
>  int X509_verify_cert(X509_STORE_CTX *ctx)
>  {
>      X509 *x, *xtmp, *xtmp2, *chain_ss = NULL;
> @@ -316,9 +350,13 @@
>                   * We have a single self signed certificate: see if 
> we can
>                   * find it in the store. We must have an exact match 
> to avoid
>                   * possible impersonation.
> +                 * get_issuer() sets up the trust store for the 
> subject and
> +                 * returns the first cert via 'xtmp'. The first cert 
> in the
> +                 * trust store may not be the certificate that we are 
> interested
> +                 * in. Look through the trust store to see there is 
> an exact match.
>                   */
>                  ok = ctx->get_issuer(&xtmp, ctx, x);
> -                if ((ok <= 0) || X509_cmp(x, xtmp)) {
> +                if ((ok <= 0) || (X509_get_cert(&xtmp, ctx, x) != 1)) {
>                      ctx->error = X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT;
>                      ctx->current_cert = x;
>                      ctx->error_depth = i - 1;
>
>
> On 10/21/17 03:21 PM, Viktor Dukhovni wrote:
>>
>> On Oct 21, 2017, at 11:20 AM, Misaki Miyashita 
>> <misaki.miyashita at oracle.com> wrote:
>>
>>> We encountered a problem using OpenLDAP with OpenSSL when there were 
>>> more than one certificate with the same subject.
>>>
>>> Does OpenSSL stop searching for a valid certificate when it finds a 
>>> certificate with matching DN?
>> Yes, when a matching issuer is found in the trust store, but is expired
>> no alternative certificates will be tested.  You need to remove outdated
>> issuer certificates from your trust store before they expire.
>>
>


From uri at ll.mit.edu  Tue Jan  9 07:46:13 2018
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Tue, 9 Jan 2018 07:46:13 +0000
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <20180109.035817.643451574880922174.levitte@openssl.org>
References: <20180105204040.5b2f5747@pc1>
 <fc576225-4efc-5d85-aaf0-b0ef92062519@gmail.com>
 <a37c4b30-0f9d-4894-ad63-35b971ffe368@default>
 <20180109.035817.643451574880922174.levitte@openssl.org>
Message-ID: <9D2C2889-8F62-4554-8B94-6054AB4C0179@ll.mit.edu>

I think being able to interoperate with IoT devices using SPECK is a good idea.

I'd like to know what kind of key exchange is likely to be used there.

Regards,
Uri

Sent from my iPhone

> On Jan 9, 2018, at 04:58, Richard Levitte <levitte at openssl.org> wrote:
> 
> I'm not terribly savvy regarding IoT, but I imagine that they do talk
> to something bigger.  A server end, perhaps?  What do we expect to run
> on that end?  What happens, in that case, if SPECK makes its way into
> the TLS cipher suites?  Would it be interesting to have OpenSSL
> interop with such devices?
> 
> Note: I'm not terribly partial either way, just thought that we need
> to look at it from a broader perspective...
> 
> Cheers,
> Richard
> 
> In message <a37c4b30-0f9d-4894-ad63-35b971ffe368 at default> on Mon, 8 Jan 2018 13:58:59 -0800 (PST), Paul Dale <paul.dale at oracle.com> said:
> 
> paul.dale> I'm wondering if one of the more specialised embedded cryptographic toolkits mightn't be a better option for your lightweight IoT TLS stack.  There is a wide choice available: CycloneSSL, ECT, Fusion, MatrixSSL, mbedTLS, NanoSSL, SharkSSL, WolfSSL, uC/SSL and many others.  All of them claim to be the smallest, fastest and most feature laden :)  To sell to the US government,  your first selection criteria should be "does the toolkit have a current FIPS validation?"  From memory this means: ECT, nanoSSL or WolfSSL.
> paul.dale> 
> paul.dale> The more comprehensive toolkits (OpenSSL, NSS, GNU TLS) are less suitable for embedded applications, especially tightly resource constrained ones.  It is possible to cut OpenSSL down in size but it will never compete with the designed for embedded toolkits.  Plus, the FIPS module is fixed and cannot be shrunk.
> paul.dale> 
> paul.dale> The current OpenSSL FIPS validation only applies to 1.0.2 builds currently.  FIPS is on the project plan for 1.1 but it isn't available at the moment.  The US government is forbidden to purchase any product that contains cryptographic operations unless the product has a FIPS validation.  No FIPS, no sale.
> paul.dale> 
> paul.dale> 
> paul.dale> Pauli
> paul.dale> -- 
> paul.dale> Oracle
> paul.dale> Dr Paul Dale | Cryptographer | Network Security & Encryption 
> paul.dale> Phone +61 7 3031 7217
> paul.dale> Oracle Australia
> paul.dale> 
> paul.dale> -----Original Message-----
> paul.dale> From: William Bathurst [mailto:wbathurs at gmail.com] 
> paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM
> paul.dale> To: openssl-dev at openssl.org
> paul.dale> Cc: Llamoureux at gmail.com
> paul.dale> Subject: Re: [openssl-dev] Speck Cipher Integration with OpenSSL
> paul.dale> 
> paul.dale> Hi Hanno/all,
> paul.dale> 
> paul.dale> I can understand your view that "more is not always good" in crypto. The reasoning behind the offering can be found in the following whitepaper:
> paul.dale> 
> paul.dale> https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf
> paul.dale> 
> paul.dale> I will summarize in a different way though. We wish to offer an optimized lightweight TLS for IoT. A majority of devices found in IoT are resource constrained, for example a device CPU may only have 32K of RAM. Therefore security is an afterthought by developers. For some only AES 128 is available and they wish to use 256 bit encryption. Then Speck
> paul.dale> 256 would be an option because it has better performance and provides sufficient security.
> paul.dale> 
> paul.dale> Based on the above scenario you can likely see why we are interested in OpenSSL. First, OpenSSL can be used for terminating lightweight TLS connections near the edge, and then forwarding using commonly used ciphers.
> paul.dale> 
> paul.dale> [IoT Device] -----TLS/Speck---->[IoT Gateway]-----TLS----> [Services]
> paul.dale> 
> paul.dale> Also, we are interested in using OpenSSL libraries at the edge for client creation. One thing we would like to do is provide instructions for an highly optimized build of OpenSSL that can be used for contrained devices.
> paul.dale> 
> paul.dale> I think demand will eventually grow because there is an initiative by the US government to improve IoT Security and Speck is being developed and proposed as a standard within the government. Therefore, I see users who wish to play in this space would be interested in a version where Speck could be used in OpenSSL.
> paul.dale> 
> paul.dale> It is my hope to accomplish the following:
> paul.dale> 
> paul.dale> [1] Make Speck available via Open Source, this could be as an option or as a patch in OpenSSL.
> paul.dale> [2] If we make it available as a patch, is there a place where we would announce/make it known that it is available?
> paul.dale> 
> paul.dale> We are also looking at open-sourcing the client side code. This would be used to create light-weight clients that use Speck and currently we also build basic OAuth capability on top of it.
> paul.dale> 
> paul.dale> Thanks for your input!
> paul.dale> 
> paul.dale> Bill
> paul.dale> 
> paul.dale> On 1/5/2018 11:40 AM, Hanno B?ck wrote:
> paul.dale> > On Fri, 5 Jan 2018 10:52:01 -0800
> paul.dale> > William Bathurst <wbathurs at gmail.com> wrote:
> paul.dale> >
> paul.dale> >> 1) Community interest in such a lightweight cipher.
> paul.dale> > I think there's a shifting view that "more is not always good" in 
> paul.dale> > crypto. OpenSSL has added features in the past "just because" and it 
> paul.dale> > was often a bad decision.
> paul.dale> >
> paul.dale> > Therefore I'd generally oppose adding ciphers without a clear usecase, 
> paul.dale> > as increased code complexity has a cost.
> paul.dale> > So I think questions that should be answered:
> paul.dale> > What's the usecase for speck in OpenSSL? Are there plans to use it in 
> paul.dale> > TLS? If yes why? By whom? What advantages does it have over existing 
> paul.dale> > ciphers? (Yeah, it's "lightweight", but that's a pretty vague thing.)
> paul.dale> >
> paul.dale> >
> paul.dale> > Also just for completeness, as some may not be aware: There are some 
> paul.dale> > concerns about Speck due to its origin (aka the NSA). I don't think 
> paul.dale> > that is a reason to dismiss a cipher right away, what I'd find more 
> paul.dale> > concerning is that from what I observed there hasn't been a lot of 
> paul.dale> > research about speck.
> paul.dale> >
> paul.dale> 
> paul.dale> --
> paul.dale> openssl-dev mailing list
> paul.dale> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> paul.dale> -- 
> paul.dale> openssl-dev mailing list
> paul.dale> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5801 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180109/114d9fc0/attachment.bin>

From beldmit at gmail.com  Tue Jan  9 08:23:33 2018
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 9 Jan 2018 11:23:33 +0300
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
Message-ID: <CADqLbzKP__2Neyt8x5e44xSC2PgzWth4bd+XKmL0VnS2gyzDDA@mail.gmail.com>

Dear William,

Does SPECK implementation need to be a part of the OpenSSL bundle itself?
It can be added as engine, similar to Russian GOST support, with minimal
patches providing OIDs/NIDs if necessary.

On Fri, Jan 5, 2018 at 9:52 PM, William Bathurst <wbathurs at gmail.com> wrote:

> Hello All,
>
> We have open sourced our work in regards to integrating the Speck Cipher
> with OpenSSL. Basic information about this cipher can be found here.
>
> https://en.wikipedia.org/wiki/Speck_(cipher) <
> https://en.wikipedia.org/wiki/Speck_%28cipher%29>
>
> SPECK is a lightweight block ciphers each of which comes in a variety of
> widths and key sizes and is targeted towards resource constrained devices
> and environments. This implementation is currently implemented using the
> 128 and 256 block sizes.
>
> We are currently modifying the source from Apache to OpenSSL open source
> licensing for the Speck/OpenSSL integration. Related repositories such as
> the cipher itself will remain under the Apache license. We would love input
> on the following items:
>
> 1) Community interest in such a lightweight cipher.
> 2) Committers willing to help on the code for improvements.
> 3) Information on how to make this available as a patch.
>
> We have currently integrated Speck with OpenSSL 1.1. We also have an Speck
> Client software available for people who wish to test this software. Future
> ports will be to mbedTLS.
>
> We have listed making it available as an issue:
>
> https://github.com/openssl/openssl/issues
>
> OpenSSL/Speck Integration open source repositories:
>
> https://github.com/m2mi/openssl_speck
> https://github.com/m2mi/open_speck
>
> Feel free to contact to to discuss the cipher and uses.
>
> With Regards,
> Bill
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180109/e610a83b/attachment.html>

From hanno at hboeck.de  Tue Jan  9 08:32:53 2018
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Tue, 9 Jan 2018 09:32:53 +0100
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <fc576225-4efc-5d85-aaf0-b0ef92062519@gmail.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <20180105204040.5b2f5747@pc1>
 <fc576225-4efc-5d85-aaf0-b0ef92062519@gmail.com>
Message-ID: <20180109093253.26007405@pc1>

Hi,

I'm not particularly convinced.

On Mon, 8 Jan 2018 13:10:07 -0800
William Bathurst <wbathurs at gmail.com> wrote:

> I will summarize in a different way though. We wish to offer an 
> optimized lightweight TLS for IoT. A majority of devices found in IoT 
> are resource constrained, for example a device CPU may only have 32K
> of RAM. Therefore security is an afterthought by developers. For some
> only AES 128 is available and they wish to use 256 bit encryption.
> Then Speck 256 would be an option because it has better performance
> and provides sufficient security.

Why would someone want a 256 bit cipher in a constrained device? This
sounds more like crypto numerology to me where people think "larger
keys are better just because". I'd take a well researched algorithm
like aes128 over a hardly researcherd 256 bit one every time.

> Based on the above scenario you can likely see why we are interested
> in OpenSSL. First, OpenSSL can be used for terminating lightweight
> TLS connections near the edge, and then forwarding using commonly
> used ciphers.

Ok, so we're talking about Speck in TLS here.
I feel this raises the bar even more and doesn't really belong here any
time soon.
Is there any effort in standardizing this? I haven't seen it on the TLS
WG mailing list and I tried to google speck tls draft and haven't found
anything.

For the record: I feel such a move - adding a new cipher to TLS -
requires much more than "we want a lightweight cipher and NSA gave us
one".
If there is serious demand for more lightweight ciphers in TLS I'd
expect some kind of open and transparent competition like it happened
with AES or SHA3 - or at least some open discussion in CFRG. However I'm
not convinced this demand even exists.


-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

From rsalz at akamai.com  Tue Jan  9 13:41:22 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Jan 2018 13:41:22 +0000
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
Message-ID: <227CE0E3-E53D-4060-AFB1-7EAF4C560272@akamai.com>


?  We are currently modifying the source from Apache to OpenSSL open source 
    licensing for the Speck/OpenSSL integration. Related repositories such 
    as the cipher itself will remain under the Apache license. We would love 
    input on the following items:

Don?t bother changing the license.  The future direction of OpenSSL is moving to Apache, anda it?s unlikely this work would show up in OpenSSL before we change the license.

We?ll soon have a blog post about our current thoughts on a crypto policy.  Watch this space.

For discussion, the future-compatible thing to do :) is open a GitHub issue.  Then, make a pull request after the issue discussion seems to have died down.

Hope this helps.


From bkaduk at akamai.com  Tue Jan  9 14:20:29 2018
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Tue, 9 Jan 2018 08:20:29 -0600
Subject: [openssl-dev] [openssl-users] Failed to access LDAP server when
 a valid certificate is at <hash>.1+
In-Reply-To: <5A5466DD.3090402@oracle.com>
References: <59EB65C1.80100@oracle.com>
 <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org>
 <5A53F4B7.8030401@oracle.com> <5A5466DD.3090402@oracle.com>
Message-ID: <91d17e8e-997d-e69b-107e-b22d2982a04c@akamai.com>

On 01/09/2018 12:53 AM, Misaki Miyashita wrote:
>
>
> On 01/ 8/18 04:46 PM, Misaki Miyashita wrote:
>> (switching the alias to openssl-dev at openssl.org)
>>
>> I would like to suggest the following fix so that a valid certificate
>> at <hash>.x can be recognized during the cert validation even when
>> <hash>.0 is linking to a bad/expired certificate.? This may not be
>> the most elegant solution, but it is a minimal change with low impact
>> to the rest of the code.
>>
>> Could I possibly get a review on the change? and possibly be
>> considered to be integrated to the upstream?
>> (This is for the 1.0.1 branch)
>
> Sorry, I meant to say it is for the 1.0.2 branch.
>

Except in exceptional circumstances, code only ends up in the 1.0.2
branch after having first gotten into the master branch and then the
1.1.0 branch.? The current release policy only allows bug fixes to be
backported to the stable branches, not new features. To me, this code
seems more like a new feature than a bugfix, though I do not claim to
speak authoritatively on the matter.

The preferred mechanism for submitting patches is as github pull
requests (against the master branch, with a note in the pull request
message if the backport is desired).

-Ben

From rsbecker at nexbridge.com  Tue Jan  9 14:32:25 2018
From: rsbecker at nexbridge.com (Randall S. Becker)
Date: Tue, 9 Jan 2018 09:32:25 -0500
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <227CE0E3-E53D-4060-AFB1-7EAF4C560272@akamai.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <227CE0E3-E53D-4060-AFB1-7EAF4C560272@akamai.com>
Message-ID: <002801d38956$aec22c30$0c468490$@nexbridge.com>

On January 9, 2018 8:41 AM, Rich Salz
> ?  We are currently modifying the source from Apache to OpenSSL open
> source
>     licensing for the Speck/OpenSSL integration. Related repositories such
>     as the cipher itself will remain under the Apache license. We would love
>     input on the following items:
> 
> Don?t bother changing the license.  The future direction of OpenSSL is moving
> to Apache, anda it?s unlikely this work would show up in OpenSSL before we
> change the license.
> 
> We?ll soon have a blog post about our current thoughts on a crypto policy.
> Watch this space.
> 
> For discussion, the future-compatible thing to do :) is open a GitHub issue.
> Then, make a pull request after the issue discussion seems to have died
> down.

A request, maybe OT. The NonStop platform does broadly deploy Apache but do use OpenSSL. I understand that OpenSSL does not officially support the HPE NonStop NSE/NSX platforms - but it is used on the platform through my team's port, which I currently support, and through other ports as well. Added a dependency to Apache is likely to dead-end the project for us depending on the depth of the dependency, if I understand where this is going (hoping I am wrong).

With respect,
Randall


From bkaduk at akamai.com  Tue Jan  9 14:45:42 2018
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Tue, 9 Jan 2018 08:45:42 -0600
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <002801d38956$aec22c30$0c468490$@nexbridge.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <227CE0E3-E53D-4060-AFB1-7EAF4C560272@akamai.com>
 <002801d38956$aec22c30$0c468490$@nexbridge.com>
Message-ID: <b1f450ee-9c45-7d78-ca14-045c1c5eca3d@akamai.com>

On 01/09/2018 08:32 AM, Randall S. Becker wrote:
> On January 9, 2018 8:41 AM, Rich Salz
>> ?  We are currently modifying the source from Apache to OpenSSL open
>> source
>>     licensing for the Speck/OpenSSL integration. Related repositories such
>>     as the cipher itself will remain under the Apache license. We would love
>>     input on the following items:
>>
>> Don?t bother changing the license.  The future direction of OpenSSL is moving
>> to Apache, anda it?s unlikely this work would show up in OpenSSL before we
>> change the license.
>>
>> We?ll soon have a blog post about our current thoughts on a crypto policy.
>> Watch this space.
>>
>> For discussion, the future-compatible thing to do :) is open a GitHub issue.
>> Then, make a pull request after the issue discussion seems to have died
>> down.
> A request, maybe OT. The NonStop platform does broadly deploy Apache but do use OpenSSL. I understand that OpenSSL does not officially support the HPE NonStop NSE/NSX platforms - but it is used on the platform through my team's port, which I currently support, and through other ports as well. Added a dependency to Apache is likely to dead-end the project for us depending on the depth of the dependency, if I understand where this is going (hoping I am wrong).
>

Apache license, not Apache software.???

-Ben

From rsbecker at nexbridge.com  Tue Jan  9 14:51:24 2018
From: rsbecker at nexbridge.com (Randall S. Becker)
Date: Tue, 9 Jan 2018 09:51:24 -0500
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <b1f450ee-9c45-7d78-ca14-045c1c5eca3d@akamai.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <227CE0E3-E53D-4060-AFB1-7EAF4C560272@akamai.com>
 <002801d38956$aec22c30$0c468490$@nexbridge.com>
 <b1f450ee-9c45-7d78-ca14-045c1c5eca3d@akamai.com>
Message-ID: <002901d38959$5560d3a0$00227ae0$@nexbridge.com>

On January 9, 2018 9:46 AM Benjamin Kaduk wrote:
> To: openssl-dev at openssl.org; Randall S. Becker <rsbecker at nexbridge.com>
> On 01/09/2018 08:32 AM, Randall S. Becker wrote:
> > On January 9, 2018 8:41 AM, Rich Salz
> >> ?  We are currently modifying the source from Apache to OpenSSL open
> >> source
> >>     licensing for the Speck/OpenSSL integration. Related repositories such
> >>     as the cipher itself will remain under the Apache license. We would love
> >>     input on the following items:
> >>
> >> Don?t bother changing the license.  The future direction of OpenSSL
> >> is moving to Apache, anda it?s unlikely this work would show up in
> >> OpenSSL before we change the license.
> >>
> >> We?ll soon have a blog post about our current thoughts on a crypto policy.
> >> Watch this space.
> >>
> >> For discussion, the future-compatible thing to do :) is open a GitHub issue.
> >> Then, make a pull request after the issue discussion seems to have
> >> died down.
> > A request, maybe OT. The NonStop platform does broadly deploy Apache
> but do use OpenSSL. I understand that OpenSSL does not officially support
> the HPE NonStop NSE/NSX platforms - but it is used on the platform through
> my team's port, which I currently support, and through other ports as well.
> Added a dependency to Apache is likely to dead-end the project for us
> depending on the depth of the dependency, if I understand where this is
> going (hoping I am wrong).
> >
> 
> Apache license, not Apache software.

Thank you thank you thank you ?, but sorry about adding noise to the conversation.
Cheers,
Randall


From rsalz at akamai.com  Tue Jan  9 15:05:24 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Jan 2018 15:05:24 +0000
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <002801d38956$aec22c30$0c468490$@nexbridge.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <227CE0E3-E53D-4060-AFB1-7EAF4C560272@akamai.com>
 <002801d38956$aec22c30$0c468490$@nexbridge.com>
Message-ID: <309A24E3-CE67-4577-B8BA-D257FBD849CA@akamai.com>

I don?t think anyone is talking about OpenSSL depending on or requiring Apache; that?s a non-starter.

It would be interesting to see how many changes you need to support your platform.


From levitte at openssl.org  Tue Jan  9 15:09:50 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 09 Jan 2018 16:09:50 +0100 (CET)
Subject: [openssl-dev]  NonStop platform support
Message-ID: <20180109.160950.1838290064897910784.levitte@openssl.org>

In message <002801d38956$aec22c30$0c468490$@nexbridge.com> on Tue, 9 Jan 2018 09:32:25 -0500, "Randall S. Becker" <rsbecker at nexbridge.com> said:

rsbecker> A request, maybe OT. The NonStop platform does broadly
rsbecker> deploy Apache but do use OpenSSL. I understand that OpenSSL
rsbecker> does not officially support the HPE NonStop NSE/NSX
rsbecker> platforms - but it is used on the platform through my team's
rsbecker> port, which I currently support, and through other ports as
rsbecker> well. Added a dependency to Apache is likely to dead-end the
rsbecker> project for us depending on the depth of the dependency, if
rsbecker> I understand where this is going (hoping I am wrong).

I pulled this away from the Speck discussion as it is indeed OT.

Does this involve some specific config target?  In that case, you
might be interested in the effort in PR 5043:
https://github.com/openssl/openssl/pull/5043

(if you claim the use of and can verify the correctness of some
specific config target(s), they can be classified as community
supported)

Cheers,
Richard

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

From rsbecker at nexbridge.com  Tue Jan  9 15:40:08 2018
From: rsbecker at nexbridge.com (Randall S. Becker)
Date: Tue, 9 Jan 2018 10:40:08 -0500
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <309A24E3-CE67-4577-B8BA-D257FBD849CA@akamai.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <227CE0E3-E53D-4060-AFB1-7EAF4C560272@akamai.com>
 <002801d38956$aec22c30$0c468490$@nexbridge.com>
 <309A24E3-CE67-4577-B8BA-D257FBD849CA@akamai.com>
Message-ID: <002a01d38960$251ed640$6f5c82c0$@nexbridge.com>

On January 9, 2018 10:05 AM, Rich Salz wrote:
> It would be interesting to see how many changes you need to support your
> platform.

Surprisingly not many at all. The platform has been significantly modernized since early ports. Most of the differences are the addition of a FLOSS layer (though #includes) and one byte swap issue on bn_mul_add_words that I'm not sure is relevant anymore. Some of the tracked files that generated (tests/Makefile) have spacing difference due to tooling differences. The code, however, is very close to vanilla as of 1.0.2n.


From rsbecker at nexbridge.com  Tue Jan  9 16:00:48 2018
From: rsbecker at nexbridge.com (Randall S. Becker)
Date: Tue, 9 Jan 2018 11:00:48 -0500
Subject: [openssl-dev] NonStop platform support
In-Reply-To: <20180109.160950.1838290064897910784.levitte@openssl.org>
References: <20180109.160950.1838290064897910784.levitte@openssl.org>
Message-ID: <002b01d38963$07943f40$16bcbdc0$@nexbridge.com>

On January 9, 2018 10:10 AM, Richard Levitte wrote:
> In message <002801d38956$aec22c30$0c468490$@nexbridge.com> on Tue,
> 9 Jan 2018 09:32:25 -0500, "Randall S. Becker" <rsbecker at nexbridge.com>
> said:
> 
> rsbecker> A request, maybe OT. The NonStop platform does broadly deploy
> rsbecker> Apache but do use OpenSSL. I understand that OpenSSL does not
> rsbecker> officially support the HPE NonStop NSE/NSX platforms - but it
> rsbecker> is used on the platform through my team's port, which I
> rsbecker> currently support, and through other ports as well. Added a
> rsbecker> dependency to Apache is likely to dead-end the project for us
> rsbecker> depending on the depth of the dependency, if I understand
> rsbecker> where this is going (hoping I am wrong).
> 
> I pulled this away from the Speck discussion as it is indeed OT.
> 
> Does this involve some specific config target?  In that case, you might be
> interested in the effort in PR 5043:
> https://github.com/openssl/openssl/pull/5043
> 
> (if you claim the use of and can verify the correctness of some specific
config
> target(s), they can be classified as community
> supported)

I'm going to bring this to my team, but expect a good outcome. The platforms
we are supporting are (from config):
    NONSTOP_KERNEL:[HJ]*:*:NSE*) # H- or J-Series, IA64
    NONSTOP_KERNEL:L*:*:NSX*) # x86-64

Cheers,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.




From hkario at redhat.com  Tue Jan  9 17:48:35 2018
From: hkario at redhat.com (Hubert Kario)
Date: Tue, 09 Jan 2018 18:48:35 +0100
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <fc576225-4efc-5d85-aaf0-b0ef92062519@gmail.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <20180105204040.5b2f5747@pc1>
 <fc576225-4efc-5d85-aaf0-b0ef92062519@gmail.com>
Message-ID: <3498962.WmkJVWtyF5@pintsize.usersys.redhat.com>

On Monday, 8 January 2018 22:10:07 CET William Bathurst wrote:
> Hi Hanno/all,
> 
> I can understand your view that "more is not always good" in crypto. The
> reasoning behind the offering can be found in the following whitepaper:
> 
> https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-20
> 15/documents/papers/session1-shors-paper.pdf
> 
> I will summarize in a different way though. We wish to offer an
> optimized lightweight TLS for IoT. A majority of devices found in IoT
> are resource constrained, for example a device CPU may only have 32K of
> RAM. Therefore security is an afterthought by developers. For some only
> AES 128 is available and they wish to use 256 bit encryption. Then Speck
> 256 would be an option because it has better performance and provides
> sufficient security.

so security is afterthought, but they got out of their way to use "more 
secure" (debatable) option?

sorry, that does not hold water
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180109/8cb6d769/attachment.sig>

From misaki.miyashita at oracle.com  Tue Jan  9 19:47:39 2018
From: misaki.miyashita at oracle.com (Misaki Miyashita)
Date: Tue, 9 Jan 2018 13:47:39 -0600
Subject: [openssl-dev] [openssl-users] Failed to access LDAP server when
 a valid certificate is at <hash>.1+
In-Reply-To: <91d17e8e-997d-e69b-107e-b22d2982a04c@akamai.com>
References: <59EB65C1.80100@oracle.com>
 <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org>
 <5A53F4B7.8030401@oracle.com> <5A5466DD.3090402@oracle.com>
 <91d17e8e-997d-e69b-107e-b22d2982a04c@akamai.com>
Message-ID: <394155c4-e949-a363-018e-b209f70138a0@oracle.com>


>> Sorry, I meant to say it is for the 1.0.2 branch.
>>
> Except in exceptional circumstances, code only ends up in the 1.0.2
> branch after having first gotten into the master branch and then the
> 1.1.0 branch.? The current release policy only allows bug fixes to be
> backported to the stable branches, not new features. To me, this code
> seems more like a new feature than a bugfix, though I do not claim to
> speak authoritatively on the matter.
>
> The preferred mechanism for submitting patches is as github pull
> requests (against the master branch, with a note in the pull request
> message if the backport is desired).

Thank so much for your comment, Ben.

We are planing to upgrade to the 1.1.0 branch as soon as we can which is 
not so easy to do at this moment as we need the FIPS capability.
Thus, we are still focusing on the 1.0.2 release, and haven't had a 
chance to work on the 1.1.0 branch.? Thus, I won't be able to submit a 
PR against the master branch at this moment.

Thus, I was hoping to get a review on the suggested fix for the 1.0.2 to 
see it is viable by the upstream first.

Would it be possible to get a review on the openssl-dev at openssl.org 
alias? or filing an issue via github is the right course of action?

Thanks again for your comment.

Regards,

-- misaki

From bkaduk at akamai.com  Tue Jan  9 20:27:21 2018
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Tue, 9 Jan 2018 14:27:21 -0600
Subject: [openssl-dev] [openssl-users] Failed to access LDAP server when
 a valid certificate is at <hash>.1+
In-Reply-To: <394155c4-e949-a363-018e-b209f70138a0@oracle.com>
References: <59EB65C1.80100@oracle.com>
 <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org>
 <5A53F4B7.8030401@oracle.com> <5A5466DD.3090402@oracle.com>
 <91d17e8e-997d-e69b-107e-b22d2982a04c@akamai.com>
 <394155c4-e949-a363-018e-b209f70138a0@oracle.com>
Message-ID: <09667013-4c58-43f0-0bd4-8bd186312b29@akamai.com>

On 01/09/2018 01:47 PM, Misaki Miyashita wrote:
>
>>> Sorry, I meant to say it is for the 1.0.2 branch.
>>>
>> Except in exceptional circumstances, code only ends up in the 1.0.2
>> branch after having first gotten into the master branch and then the
>> 1.1.0 branch.? The current release policy only allows bug fixes to be
>> backported to the stable branches, not new features. To me, this code
>> seems more like a new feature than a bugfix, though I do not claim to
>> speak authoritatively on the matter.
>>
>> The preferred mechanism for submitting patches is as github pull
>> requests (against the master branch, with a note in the pull request
>> message if the backport is desired).
>
> Thank so much for your comment, Ben.
>
> We are planing to upgrade to the 1.1.0 branch as soon as we can which
> is not so easy to do at this moment as we need the FIPS capability.
> Thus, we are still focusing on the 1.0.2 release, and haven't had a
> chance to work on the 1.1.0 branch.? Thus, I won't be able to submit a
> PR against the master branch at this moment.
>
> Thus, I was hoping to get a review on the suggested fix for the 1.0.2
> to see it is viable by the upstream first.
>
> Would it be possible to get a review on the openssl-dev at openssl.org
> alias? or filing an issue via github is the right course of action?
>

You already got a review, from Viktor.? I don't think there's much
reason to file an issue in github without a patch (and if there's a
patch, it should just go straight to a pull request with no separate
issue).? If you want the feature to get upstreamed, the onus is on you
to forward-port the patch to master and adapt it to review comments; I
don't think we've seen sufficient interest to cause a team member to
spontaneously take that work upon themselves.

-Ben

> Thanks again for your comment.
>
> Regards,
>
> -- misaki


From misaki.miyashita at oracle.com  Tue Jan  9 20:43:39 2018
From: misaki.miyashita at oracle.com (Misaki Miyashita)
Date: Tue, 9 Jan 2018 14:43:39 -0600
Subject: [openssl-dev] [openssl-users] Failed to access LDAP server when
 a valid certificate is at <hash>.1+
In-Reply-To: <09667013-4c58-43f0-0bd4-8bd186312b29@akamai.com>
References: <59EB65C1.80100@oracle.com>
 <80538E95-D469-4208-A7E1-39111C64AB4C@dukhovni.org>
 <5A53F4B7.8030401@oracle.com> <5A5466DD.3090402@oracle.com>
 <91d17e8e-997d-e69b-107e-b22d2982a04c@akamai.com>
 <394155c4-e949-a363-018e-b209f70138a0@oracle.com>
 <09667013-4c58-43f0-0bd4-8bd186312b29@akamai.com>
Message-ID: <3c009cc2-ba7b-409a-1577-2c925e1d5003@oracle.com>


>> Thank so much for your comment, Ben.
>>
>> We are planing to upgrade to the 1.1.0 branch as soon as we can which
>> is not so easy to do at this moment as we need the FIPS capability.
>> Thus, we are still focusing on the 1.0.2 release, and haven't had a
>> chance to work on the 1.1.0 branch.? Thus, I won't be able to submit a
>> PR against the master branch at this moment.
>>
>> Thus, I was hoping to get a review on the suggested fix for the 1.0.2
>> to see it is viable by the upstream first.
>>
>> Would it be possible to get a review on the openssl-dev at openssl.org
>> alias? or filing an issue via github is the right course of action?
>>
> You already got a review, from Viktor.

I totally missed the review from Viktor.? I'll follow up on the thread.
Sorry about that.

>  ? I don't think there's much
> reason to file an issue in github without a patch (and if there's a
> patch, it should just go straight to a pull request with no separate
> issue).? If you want the feature to get upstreamed, the onus is on you
> to forward-port the patch to master and adapt it to review comments; I
> don't think we've seen sufficient interest to cause a team member to
> spontaneously take that work upon themselves.

Understood.? Thanks for your input.
Once we move to the 1.1 release train, we will look into the issue and 
submit a PR.

Thank you,

-- misaki

From wbathurs at gmail.com  Wed Jan 10 02:41:25 2018
From: wbathurs at gmail.com (William Bathurst)
Date: Tue, 9 Jan 2018 18:41:25 -0800
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <87o9m89k2g.fsf@fifthhorseman.net>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <87o9m89k2g.fsf@fifthhorseman.net>
Message-ID: <1f3e061a-1a63-c41c-b03b-67eefbacf24f@gmail.com>

Hi dkg,

You stated the following:

My understanding is that the algorithm designers and primary advocates
have not been particularly forthcoming with their design goals, and
their reputation is mixed, at best.

Simon and Speck has been in the public domain for a number of years and 
there are quite a few white papers and articles on the Ciphers. Allowing 
public scrutiny and crypto-analysis is one way to put a cipher through 
the grinder to make sure there are no back doors or weaknesses.

Regards,
Bill


On 1/5/2018 11:33 AM, Daniel Kahn Gillmor wrote:
> Hi Bill--
>
> On Fri 2018-01-05 10:52:01 -0800, William Bathurst wrote:
>
>> We have open sourced our work in regards to integrating the Speck Cipher
>> with OpenSSL. Basic information about this cipher can be found here.
>>
>> https://en.wikipedia.org/wiki/Speck_(cipher)
>> <https://en.wikipedia.org/wiki/Speck_%28cipher%29>
>>
>> SPECK is a lightweight block ciphers each of which comes in a variety of
>> widths and key sizes and is targeted towards resource constrained
>> devices and environments. This implementation is currently implemented
>> using the 128 and 256 block sizes.
> Thanks for your work on this, and for reporting on it here.  Out of
> curiosity, who is the "We" involved here?  The changeset history
> appears to be a bit ambivalent about the authorship, based on edits to
> the README itself:
>
>    https://github.com/m2mi/openssl_speck/commit/4a67a5644ff5c56956063d858033585f57686d1e
>    https://github.com/m2mi/openssl_speck/commit/8d619beffa3bd1c221fc6a7946b9aa7a00774019
>
>> 1) Community interest in such a lightweight cipher.
> I'm not convinced that the OpenSSL project should encourage the adoption
> of SPECK, given the general level of distrust around the algorithm:
>
>    https://www.schneier.com/blog/archives/2017/09/iso_rejects_nsa.html
>
> My understanding is that the algorithm designers and primary advocates
> have not been particularly forthcoming with their design goals, and
> their reputation is mixed, at best.
>
> Regards,
>
>        --dkg


From wbathurs at gmail.com  Wed Jan 10 02:45:36 2018
From: wbathurs at gmail.com (William Bathurst)
Date: Tue, 9 Jan 2018 18:45:36 -0800
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <CADqLbzKP__2Neyt8x5e44xSC2PgzWth4bd+XKmL0VnS2gyzDDA@mail.gmail.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <CADqLbzKP__2Neyt8x5e44xSC2PgzWth4bd+XKmL0VnS2gyzDDA@mail.gmail.com>
Message-ID: <72ef294d-dc4a-cc24-fbf8-c0d8ea008597@gmail.com>

Hi Dmitry,

We implemented it using the same means as we saw the other ciphers. It 
was using the EVP functions. This way it could be included or excluded 
via makefile.

Regards,
Bill


On 1/9/2018 12:23 AM, Dmitry Belyavsky wrote:
> Dear William,
>
> Does SPECK implementation need to be a part of the OpenSSL bundle itself?
> It can be added as engine, similar to Russian GOST support, with 
> minimal patches providing OIDs/NIDs if necessary.
>
> On Fri, Jan 5, 2018 at 9:52 PM, William Bathurst <wbathurs at gmail.com 
> <mailto:wbathurs at gmail.com>> wrote:
>
>     Hello All,
>
>     We have open sourced our work in regards to integrating the Speck
>     Cipher with OpenSSL. Basic information about this cipher can be
>     found here.
>
>     https://en.wikipedia.org/wiki/Speck_(cipher)
>     <https://en.wikipedia.org/wiki/Speck_%28cipher%29>
>     <https://en.wikipedia.org/wiki/Speck_%28cipher%29
>     <https://en.wikipedia.org/wiki/Speck_%28cipher%29>>
>
>     SPECK is a lightweight block ciphers each of which comes in a
>     variety of widths and key sizes and is targeted towards resource
>     constrained devices and environments. This implementation is
>     currently implemented using the 128 and 256 block sizes.
>
>     We are currently modifying the source from Apache to OpenSSL open
>     source licensing for the Speck/OpenSSL integration. Related
>     repositories such as the cipher itself will remain under the
>     Apache license. We would love input on the following items:
>
>     1) Community interest in such a lightweight cipher.
>     2) Committers willing to help on the code for improvements.
>     3) Information on how to make this available as a patch.
>
>     We have currently integrated Speck with OpenSSL 1.1. We also have
>     an Speck Client software available for people who wish to test
>     this software. Future ports will be to mbedTLS.
>
>     We have listed making it available as an issue:
>
>     https://github.com/openssl/openssl/issues
>     <https://github.com/openssl/openssl/issues>
>
>     OpenSSL/Speck Integration open source repositories:
>
>     https://github.com/m2mi/openssl_speck
>     <https://github.com/m2mi/openssl_speck>
>     https://github.com/m2mi/open_speck
>     <https://github.com/m2mi/open_speck>
>
>     Feel free to contact to to discuss the cipher and uses.
>
>     With Regards,
>     Bill
>
>     -- 
>     openssl-dev mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-dev
>     <https://mta.openssl.org/mailman/listinfo/openssl-dev>
>
>
>
>
> -- 
> SY, Dmitry Belyavsky
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180109/56a81d09/attachment.html>

From wiml at omnigroup.com  Wed Jan 10 04:26:54 2018
From: wiml at omnigroup.com (Wim Lewis)
Date: Tue, 9 Jan 2018 20:26:54 -0800
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <002a01d38960$251ed640$6f5c82c0$@nexbridge.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <227CE0E3-E53D-4060-AFB1-7EAF4C560272@akamai.com>
 <002801d38956$aec22c30$0c468490$@nexbridge.com>
 <309A24E3-CE67-4577-B8BA-D257FBD849CA@akamai.com>
 <002a01d38960$251ed640$6f5c82c0$@nexbridge.com>
Message-ID: <11B3CE12-E7D3-4AEA-A7BD-0B21840C8B6A@omnigroup.com>


On 9. jan. 2018, at 7:40 f.h., Randall S. Becker <rsbecker at nexbridge.com> wrote:
> On January 9, 2018 10:05 AM, Rich Salz wrote:
>> It would be interesting to see how many changes you need to support your
>> platform.
> 
> Surprisingly not many at all. The platform has been significantly modernized since early ports. Most of the differences are the addition of a FLOSS layer (though #includes) and one byte swap issue on bn_mul_add_words that I'm not sure is relevant anymore. Some of the tracked files that generated (tests/Makefile) have spacing difference due to tooling differences. The code, however, is very close to vanilla as of 1.0.2n.

In this case, I think Dmitry Belyavsky's suggestion makes the most sense. SPECK can be built as an ENGINE, the same way that GOST, CAPI, etc. are. (see [1].) This may require small changes to OpenSSL proper (to add OIDs, say), but they should be small enough not to add any complexity or maintenance burden to OpenSSL. If/when SPECK gains more use, or is considered for standardization in TLS, etc., then this codebase can be moved into OpenSSL's. In the meantime, people can build the SPECK engine to use it in an OpenSSL-based program.

[1] https://github.com/gost-engine/engine


From dkg at fifthhorseman.net  Wed Jan 10 07:30:59 2018
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 10 Jan 2018 02:30:59 -0500
Subject: [openssl-dev] Speck Cipher Integration with OpenSSL
In-Reply-To: <1f3e061a-1a63-c41c-b03b-67eefbacf24f@gmail.com>
References: <c1c5c83e-0844-0776-37c0-93e384759286@gmail.com>
 <87o9m89k2g.fsf@fifthhorseman.net>
 <1f3e061a-1a63-c41c-b03b-67eefbacf24f@gmail.com>
Message-ID: <878td641cc.fsf@fifthhorseman.net>

On Tue 2018-01-09 18:41:25 -0800, William Bathurst wrote:
> [ dkg wrote: ]
>> My understanding is that the algorithm designers and primary advocates
>> have not been particularly forthcoming with their design goals, and
>> their reputation is mixed, at best.
>
> Simon and Speck has been in the public domain for a number of years and 
> there are quite a few white papers and articles on the Ciphers. Allowing 
> public scrutiny and crypto-analysis is one way to put a cipher through 
> the grinder to make sure there are no back doors or weaknesses.

It sounds like we agree that adversarial cryptanalysis is a necessary
component of evaluating cryptographic algorithms today. :)

And yes, Simon and Speck have indeed been published for a while now.  My
understanding is that there has been a steady stream of cryptanalysis
against them, which has made some non-negligible progress in whittling
down their initially-claimed security levels.

Meanwhile (as i said above), the designers have not been particularly
forthcoming with producing their design goals and their own
cryptanalysis, despite requests for those documents.  Shouldn't the
designers of algorithms intended to be used by the public also be
transparent about their design goals and their own understanding of the
strengths and weaknesses of the algorithms they're proposing?  This
seems particularly relevant when the designers have been plausibly
accused of trying to pass off sub-standard cryptographic algorithms as
acceptable for public consumption (e.g. "we got punked" as one NIST
representative described the Dual EC DRBG fiasco).

I'd personally like to see documentation of the internal design goals
and cryptanalysis from the authors of Simon and Speck before considering
it for wider adoption, especially given that reasonably efficient strong
ciphers are already available.  Or do you think that knowing the
designers' goals and internal analysis should not a relevant criterion
for consideration?

Regards,

           --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180110/78ac8cdd/attachment.sig>

From matt at openssl.org  Wed Jan 10 23:16:46 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 10 Jan 2018 23:16:46 +0000
Subject: [openssl-dev] OpenSSL wins the Levchin prize
Message-ID: <457054ae-e8ee-a8c5-67d4-d5e1d52ac70e@openssl.org>

Today I have had great pleasure in attending the Real World Crypto 2018
conference in Z?rich in order to receive the Levchin prize on behalf of
the OpenSSL team. More details are available in my blog post here:

https://www.openssl.org/blog/blog/2018/01/10/levchin/

Matt

From rsbecker at nexbridge.com  Thu Jan 11 22:54:56 2018
From: rsbecker at nexbridge.com (Randall S. Becker)
Date: Thu, 11 Jan 2018 17:54:56 -0500
Subject: [openssl-dev] NonStop platform support
In-Reply-To: <20180109.160950.1838290064897910784.levitte@openssl.org>
References: <20180109.160950.1838290064897910784.levitte@openssl.org>
Message-ID: <001501d38b2f$36dc3000$a4949000$@nexbridge.com>

On January 9, 2018 10:10 AM, Richard Levitte wrote:
> On Jan 2018 09:32:25 -0500, "Randall S. Becker" <rsbecker at nexbridge.com>
said:
> 
> rsbecker> A request, maybe OT. The NonStop platform does broadly deploy
> rsbecker> Apache but do use OpenSSL. I understand that OpenSSL does not
> rsbecker> officially support the HPE NonStop NSE/NSX platforms - but it
> rsbecker> is used on the platform through my team's port, which I
> rsbecker> currently support, and through other ports as well. Added a
> rsbecker> dependency to Apache is likely to dead-end the project for us
> rsbecker> depending on the depth of the dependency, if I understand
> rsbecker> where this is going (hoping I am wrong).
> 
> I pulled this away from the Speck discussion as it is indeed OT.
> 
> Does this involve some specific config target?  In that case, you might be
> interested in the effort in PR 5043:
> https://github.com/openssl/openssl/pull/5043
> 
> (if you claim the use of and can verify the correctness of some specific
config
> target(s), they can be classified as community
> supported)

I am authorized to claim that the ITUGLIB team (including myself) can
support this effort for the following config targets:
    NONSTOP_KERNEL:[HJ]*:*:NSE* # H- or J-Series, IA64
    NONSTOP_KERNEL:L*:*:NSX*) # x86-64

Our current port is current with 1.0.2n with platform mods. I have posted
such to the 5043 pull discussion and can create a pull request with our
modifications for review.

Regards,
Randall


From dnsands at sandia.gov  Mon Jan 15 18:17:08 2018
From: dnsands at sandia.gov (Sands, Daniel)
Date: Mon, 15 Jan 2018 18:17:08 +0000
Subject: [openssl-dev] PKCS12 safecontents bag type deviation from spec
Message-ID: <1516040228.9330.7.camel@sandia.gov>

After noticing that a safecontents bag written to a file was in a
different order than I added them, I did some experimentation and
discovered that it's sorting the list, which led me to notice that it's
defining a safecontentsbag as a SET OF safecontents, which causes
sorting:



ASN1_ADB(PKCS12_SAFEBAG) = {
????????ADB_ENTRY(NID_keyBag, ASN1_EXP(PKCS12_SAFEBAG, value.keybag,
PKCS8_PRIV_KEY_INFO, 0)),
????????ADB_ENTRY(NID_pkcs8ShroudedKeyBag, ASN1_EXP(PKCS12_SAFEBAG,
value.shkeybag, X509_SIG, 0)),
????????ADB_ENTRY(NID_safeContentsBag, ASN1_EXP_SET_OF(PKCS12_SAFEBAG,
value.safes, PKCS12_SAFEBAG, 0)),
????????ADB_ENTRY(NID_certBag, ASN1_EXP(PKCS12_SAFEBAG, value.bag,
PKCS12_BAGS, 0)),
????????ADB_ENTRY(NID_crlBag, ASN1_EXP(PKCS12_SAFEBAG, value.bag,
PKCS12_BAGS, 0)),
????????ADB_ENTRY(NID_secretBag, ASN1_EXP(PKCS12_SAFEBAG, value.bag,
PKCS12_BAGS, 0))
} ASN1_ADB_END(PKCS12_SAFEBAG, 0, type, 0, &safebag_default_tt, NULL);




PKCS12 specifies that a safecontents bag is a SEQUENCE OF safecontents,
just like the top-level authsafe is:



SafeContents ::= SEQUENCE OF SafeBag

...

The sixth type of bag that can be held in a SafeBag is a
???SafeContents.




Is the deviation from the spec intentional?

From rsalz at akamai.com  Tue Jan 16 14:50:02 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 16 Jan 2018 14:50:02 +0000
Subject: [openssl-dev] PKCS12 safecontents bag type deviation from spec
Message-ID: <92C69AC3-A89E-405D-814E-D4B0DE024666@akamai.com>

OpenSSL defines it as a SET OF and the spec says it?s a SEQUENCE OF.  Ouch!  Will that cause interop problems if we change it?  (I don?t remember the DER encoding rules)




From mcr at sandelman.ca  Tue Jan 16 15:32:07 2018
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 16 Jan 2018 10:32:07 -0500
Subject: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)
In-Reply-To: <24932.1515179901@obiwan.sandelman.ca>
References: <24932.1515179901@obiwan.sandelman.ca>
Message-ID: <17541.1516116727@obiwan.sandelman.ca>

please see https://github.com/openssl/openssl/pull/5024

mattcaswell asks on github:
    mattcaswell> I am unclear about the underlying premise of this PR:

    mcr>     This patch refactors the DTLSv1_listen() to create an
    mcr> alternative API that is called DTLSv1_accept().
    mcr> DTLSv1_accept() is useable by programs that need to treat
    mcr> DTLS interfaces in a way similar to TCP: new connections
    mcr> must be accepted, and new sockets created.

    mattcaswell> Your going to give more justification than this. Why is it
    mattcaswell> that DTLSv1_listen() is not appropriate for your use case?

As I understand using DTLSv1_listen(), one does the following:
  1) open a UDP socket, bind(2) it appropriately.
     {in an RTP context, one might already know the remote port numbers, and
     one could connect(2) it already. In the CoAP case, that certainly is not
     the case}
     Put the socket into an SSL, do appropriate blocking or non-blocking
     event handling in application.

  2) call DTLSv1_listen() when there is traffic.
     DTLSv1_listen() will process (via peek) the first packet in the socket.
     If it's a Client Hello without a cookie, then a Hello Verify is sent
     back (%).  If it ate the packet, then it loops until it find something
     it can't handle or runs out of packets.

  3) DTLSv1_listen(), when it finds a Client Hello with a cookie, marks the
     provided SSL as having transitioned to a state where things can start,
     and it returns 1, along with the BIO_ADDR of the newly Verify Hello'ed client.

  4) the application is now expected to connect() the FD to the BIO_ADDR,
     and call SSL_accept(), and then to proceed with SSL_read()/SSL_write(), etc.

Perhaps I've gotten something wrong with this process.

This flow is entirely appropriate for a RTP user, but for a CoAP server there
are a number of problems:

a) when the existing FD is connect(2) any future traffic to the bound port
   will get rejected with no port.  So the application really has to open a
   new socket first.
   The application can do this two ways: it can open a new socket on which to receive
   new connections, or it can open a new socket on which to communicate with
   the new client.    The second method is better for reason (b) below.
   Either way, it socket to communicate with the client needs to be bind(2)
   to the address that the client used to communicate with the server, and
   DTLSv1_listen() didn't collect or return that information.

b) the existing FD might have additional packets from other clients. This
   argues for opening a new socket for the new client, and leaving the queue
   on the existing FD.

c) the DTLSv1_listen() uses the SSL* (and associated CTX) that is provided to
   it for callbacks, and cookie verification.  It modifies the state of that
   SSL* to continue the transaction.
   I think that the roles should be split up.

also, from point (2) above:
(%) - the send that DTLSv1_listen() depends upon the socket having been
    bind(2) with a non-INADDR_ANY/IN6ADDR_ANY_INIT IP address, or that the
    system in question has only a single IP address.  This is because the
    write that is done relies upon the kernel to pick the right source
    address,  which appears to be easy for IPv4 with a single interface, but
    trivially can fail for IPv6 even with a single interface due to
    temporary, stable-private, and link-local addresses.


DTLSv1_accept() takes two SSL*.  The first is used for cookie verification,
while the second is filled in with a new FD that has been bind/connect to the
client and state advanced to be ready for SSL_accept().  It also returns the
same BIO_ADDR for the client, but that could be removed as it can trivially
be retrieved from the new SSL*.

    mattcaswell> In any case the PR as it currently stands is a very long way
    mattcaswell> off being acceptable:

I totally agree, but I had to post something to start the conversation.

    mattcaswell> * As you point out the use of the POSIX socket APIs is
    mattcaswell> unacceptable and is at the wrong level of abstraction. I
    mattcaswell> might perhaps expect to see this sort of thing in the BIO
    mattcaswell> layer.

a) I could move the socket creation code into BIO layer, a new BIO_ctrl method
   could be created to "duplicate" the BIO.  This would probably eliminate
   having to expose BIO_ADDR_sockaddr{,_size} from libcrypto->libssl.

b) creation of a new socket could be a new callback.

c) DTLSv1_accept() could return at:
   "now set up a socket based upon the original rbio's peer/addr"
   as all of the subsequent operations could be done by the application given
     BIO_dgram_get_peer(rbio, client) and BIO_dgram_get_addr(rbio, ouraddr)

d) a combination of (a) and (c), where the duplication code is provided by
   the BIO layer, but the application could do something different if it
   needed to.

My preference is for (d), because I think that it's common code and the
application writer will get it wrong.  In particular, you need to open the
socket with SO_REUSEPORT in order to be allowed to bind() the new socket
before connect(2)ing it.  If there were a system call to do both at the same
time it would be better.  There is a race condition by calling bind() first,
because the kernel is likely to put new traffic from new sources into the
new socket.  They will be dropped as having the wrong cookies.

    mattcaswell> * The code does not seem to be portable - it needs
    mattcaswell> to work on all our platforms

    mattcaswell> * There is no documentation

I will write more documentation when I am sure what the structure is going to be.

    mattcaswell> I noticed a number of other things at a more specific level,
    mattcaswell> just scanning through the code, but at this point I have not
    mattcaswell> reviewed it in detail. I am not yet convinced there is a
    mattcaswell> need for this.

I absolutely need to have recvmsg()/sendmsg() in the bss_dgram.c in order to
get the destination address used.   This IPv6 code is portable, since the RFC
API says how to do it.

The IPv4 code varies by OS; I can probably write the correct thing and get
tested it on FreeBSD, but I have no idea about Windows.  We used to solve
this by opening a socket for each interface and listening to the routing
socket, or having a human configure an explicit list of interfaces, or just
failing on multi-homed hosts.

I propose to split this pull request up into one that deals with the changes
to the BIO layer only.
A second pull request will include the "duplicate" BIO functionality.

A third then deals with the d1_lib.c layer.



--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


From matt at openssl.org  Tue Jan 16 16:46:32 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 16 Jan 2018 16:46:32 +0000
Subject: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)
In-Reply-To: <17541.1516116727@obiwan.sandelman.ca>
References: <24932.1515179901@obiwan.sandelman.ca>
 <17541.1516116727@obiwan.sandelman.ca>
Message-ID: <ada89d1a-f4a7-ecb0-ef31-f2c8e4d1905b@openssl.org>



On 16/01/18 15:32, Michael Richardson wrote:
> 
> a) when the existing FD is connect(2) any future traffic to the bound port
>    will get rejected with no port.  So the application really has to open a
>    new socket first.
>    The application can do this two ways: it can open a new socket on which to receive
>    new connections, or it can open a new socket on which to communicate with
>    the new client.    The second method is better for reason (b) below.
>    Either way, it socket to communicate with the client needs to be bind(2)
>    to the address that the client used to communicate with the server, and
>    DTLSv1_listen() didn't collect or return that information.

The second way is what is intended. Maybe I misunderstand your point -
but the client address *is* returned? Admittedly its wrapped in a
BIO_ADDR, but its easy to get the underlying "raw" address using
BIO_ADDR_rawaddress():

https://www.openssl.org/docs/man1.1.0/crypto/BIO_ADDR_rawaddress.html

i.e. call BIO_ADDR_rawaddress() on the BIO_ADDR returned by
DTLSv1_listen() and then do something like this:

 /* Handle client connection */
 int client_fd = socket(AF_INET6, SOCK_DGRAM, 0);
 bind(client_fd, &server_addr, sizeof(struct sockaddr_in6));
 connect(client_fd, &client_addr, sizeof(struct sockaddr_in6));
 /* Set new fd and set BIO to connected */
 BIO *cbio = SSL_get_rbio(ssl);
 BIO_set_fd(cbio, client_fd, BIO_NOCLOSE);
 BIO_ctrl(cbio, BIO_CTRL_DGRAM_SET_CONNECTED, 0, &client_addr);
 /* Finish handshake */
 SSL_accept(ssl);

> 
> b) the existing FD might have additional packets from other clients. This
>    argues for opening a new socket for the new client, and leaving the queue
>    on the existing FD.

Which is what I recommend.


> I absolutely need to have recvmsg()/sendmsg() in the bss_dgram.c in order to
> get the destination address used.   This IPv6 code is portable, since the RFC
> API says how to do it.

Why isn't recvfrom() suitable (which is what the code currently uses to
get the address)?

Matt

From dnsands at sandia.gov  Tue Jan 16 19:31:11 2018
From: dnsands at sandia.gov (Sands, Daniel)
Date: Tue, 16 Jan 2018 19:31:11 +0000
Subject: [openssl-dev] [EXTERNAL] Re: PKCS12 safecontents bag type
 deviation from spec
In-Reply-To: <92C69AC3-A89E-405D-814E-D4B0DE024666@akamai.com>
References: <92C69AC3-A89E-405D-814E-D4B0DE024666@akamai.com>
Message-ID: <1516131071.9330.13.camel@sandia.gov>

On Tue, 2018-01-16 at 14:50 +0000, Salz, Rich via openssl-dev wrote:
> OpenSSL defines it as a SET OF and the spec says it?s a SEQUENCE
> OF.??Ouch!??Will that cause interop problems if we change it???(I
> don?t remember the DER encoding rules)
> 
> 
> 

Well, a SEQUENCE uses tag 16 while a SET uses tag 17, according to a
quick reference I found.  So that could be an interoperability concern.
 But maybe this is the first actual use of nested safecontents, since
this difference flew under the radar for so long :)

From mcr at sandelman.ca  Tue Jan 16 19:44:38 2018
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 16 Jan 2018 14:44:38 -0500
Subject: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)
In-Reply-To: <ada89d1a-f4a7-ecb0-ef31-f2c8e4d1905b@openssl.org>
References: <24932.1515179901@obiwan.sandelman.ca>
 <17541.1516116727@obiwan.sandelman.ca>
 <ada89d1a-f4a7-ecb0-ef31-f2c8e4d1905b@openssl.org>
Message-ID: <13999.1516131878@obiwan.sandelman.ca>


Matt Caswell <matt at openssl.org> wrote:
    >> a) when the existing FD is connect(2) any future traffic to the bound
    >> port will get rejected with no port.  So the application really has to
    >> open a new socket first.  The application can do this two ways: it can
    >> open a new socket on which to receive new connections, or it can open
    >> a new socket on which to communicate with the new client.  The second
    >> method is better for reason (b) below.  Either way, it socket to
    >> communicate with the client needs to be bind(2) to the address that
    >> the client used to communicate with the server, and DTLSv1_listen()
    >> didn't collect or return that information.

    > The second way is what is intended.

Unfortunately, there remains a race condition because we have to call bind()
before connect() on the new socket.  Under load, if a packet is received
between the bind() and the connect(), it might go onto the wrong socket
queue. So some packets that could have been processed will get dropped and
have to be retransmitted by the client.

It could be solved if there was a way to punt packets received on the wrong
socket to the correct BIO on the input side.  I looked into this, but decided
it was too difficult...

That would also let one operate a multitude of DTLS connections using single
socket which might be a boon to some users.  Mis-designed it would scale
badly on multi-threaded machines and involve lots of ugly locks.
I don't want to consider the impacts if one had to pass packets between processes...
I don't advocate a solution like this (I'll live with the dropped packets),
but I think it's worth making people aware that they might see mis-directed
packets get dropped.

    > Maybe I misunderstand your point -
    > but the client address *is* returned? Admittedly its wrapped in a
    > BIO_ADDR, but its easy to get the underlying "raw" address using
    > BIO_ADDR_rawaddress():

    > Why isn't recvfrom() suitable (which is what the code currently uses to
    > get the address)?

The address of the remote client is returned ("getpeername()") by DTLSv1_listen().
That's all that recvfrom() gives you.

recvfrom() was a reasonable API for SunOS 3.x machines with a single 10Mb/s
interface with a single IPv4 address.  I loved all that at the time...
But it doesn't work that well when we might have a dozen different kind of
IPv6 addresses on each virtual interface.

The address that I'm talking about needing is the one the remote client used
to reach us.  That's the destination IP of the incoming packet ("getsockname()" in TCP speak).

With TCP this is never an issue because the kernel creates the new socket and
copies the right stuff in for us when it creates the socket.

With UDP, the source address for outgoing packets needs to match or the
client may get a response from an address that it didn't connect to.  Worse,
there might be firewalls or policy routing that would cause the packet to
disappear or get routed differently.  In my application, I definitely dealing
with connections over IPv6 Link-Local addresses with a multitude of virtual
links.

In your code example:
    bind(client_fd, &server_addr, sizeof(struct sockaddr_in6));

server_addr has to be set from the destination address of the incoming
packet, it's not a global that the admin set, or the SIP negotiated.

In the bad old days, this meant opening a socket for every interface on the
machine, and re-reading the list of interfaces based upon some heuristic.
(routing socket, SIGHUP, ...)

Even getting a list of interfaces (and their addresses) is itself a
OS-dependant activity!  And, if you use the old BSD interface on Linux,
you'll miss a bunch of interfaces, because the Linux kernel people thought
that it would confuse BSD APIs if interfaces were returned that the BSD
interface didn't create.  So you can't even win there.

The IPv6 API gives us recvmsg() and ipi6_pktinfo, which makes it all sane.
But, we never got a standard interface for IPv4: Linux uses something that
looks identical to IPv6, and BSD has something with slightly different names.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180116/8a530fa3/attachment-0001.sig>

From matt at openssl.org  Tue Jan 16 22:36:33 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 16 Jan 2018 22:36:33 +0000
Subject: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)
In-Reply-To: <13999.1516131878@obiwan.sandelman.ca>
References: <24932.1515179901@obiwan.sandelman.ca>
 <17541.1516116727@obiwan.sandelman.ca>
 <ada89d1a-f4a7-ecb0-ef31-f2c8e4d1905b@openssl.org>
 <13999.1516131878@obiwan.sandelman.ca>
Message-ID: <fd968187-1537-ea93-c797-f6e3ad700eaa@openssl.org>



On 16/01/18 19:44, Michael Richardson wrote:
> 
> Matt Caswell <matt at openssl.org> wrote:
>     >> a) when the existing FD is connect(2) any future traffic to the bound
>     >> port will get rejected with no port.  So the application really has to
>     >> open a new socket first.  The application can do this two ways: it can
>     >> open a new socket on which to receive new connections, or it can open
>     >> a new socket on which to communicate with the new client.  The second
>     >> method is better for reason (b) below.  Either way, it socket to
>     >> communicate with the client needs to be bind(2) to the address that
>     >> the client used to communicate with the server, and DTLSv1_listen()
>     >> didn't collect or return that information.
> 
>     > The second way is what is intended.
> 
> Unfortunately, there remains a race condition because we have to call bind()
> before connect() on the new socket.  Under load, if a packet is received
> between the bind() and the connect(), it might go onto the wrong socket
> queue. So some packets that could have been processed will get dropped and
> have to be retransmitted by the client.

This seems like a non-issue to me. At this point in the handshake the
client will have sent its ClientHello and won't progress until it gets
the server's flight back (ServerHello etc), i.e. in the vast majority of
cases it won't be sending anything.

It is possible that the client may retransmit the ClientHello if the
server hasn't responded within a timely manner. Retransmit times are
usually quite a while (relatively speaking) after the original
transmission, so the chances of this happening immediately after we've
processed the original ClientHello and before we've called connect()
seem quite small - although possible. If a retransmitted ClientHello
arrives *after* the connect() it will be dropped anyway by OpenSSL so we
really don't care about these messages going missing.

Another possibility is that the client transmits an alert of some form.
This also seems quite unlikely (i.e. send a ClientHello and then
immediately send an alert before the server has had a chance to respond)
- but again, its possible. It would be bad luck indeed for this unlikely
scenario to happen and then for the alert to not make it onto the right
fd due to the race: but if it did its not a big deal. This connection is
doomed in any case (an alert was sent) and we have to be prepared to
deal with packets getting dropped anyway (this is DTLS!). It is very
common for clients to just abort without sending an alert anyway - so
this will just appear like that.

> 
> It could be solved if there was a way to punt packets received on the wrong
> socket to the correct BIO on the input side.  I looked into this, but decided
> it was too difficult...
> 
> That would also let one operate a multitude of DTLS connections using single
> socket which might be a boon to some users.  Mis-designed it would scale
> badly on multi-threaded machines and involve lots of ugly locks.
> I don't want to consider the impacts if one had to pass packets between processes...
> I don't advocate a solution like this (I'll live with the dropped packets),
> but I think it's worth making people aware that they might see mis-directed
> packets get dropped.
> 
>     > Maybe I misunderstand your point -
>     > but the client address *is* returned? Admittedly its wrapped in a
>     > BIO_ADDR, but its easy to get the underlying "raw" address using
>     > BIO_ADDR_rawaddress():
> 
>     > Why isn't recvfrom() suitable (which is what the code currently uses to
>     > get the address)?
> 
> The address of the remote client is returned ("getpeername()") by DTLSv1_listen().
> That's all that recvfrom() gives you.
> 
> recvfrom() was a reasonable API for SunOS 3.x machines with a single 10Mb/s
> interface with a single IPv4 address.  I loved all that at the time...
> But it doesn't work that well when we might have a dozen different kind of
> IPv6 addresses on each virtual interface.
> 
> The address that I'm talking about needing is the one the remote client used
> to reach us.  That's the destination IP of the incoming packet ("getsockname()" in TCP speak).

Ahhh....its the *server's* address you are after. This requirement seems
more reasonable. I think the API is designed to expect you to only bind
to a single IP. I'd be interested in Richard Levitte's opinion on this.

It seems like a fairly simple solution could solve this. Currently we
have BIO_dgram_get_peer() which returns the peer's address for the last
message read from a BIO. You could imagine a new call being introduced
to get our own address. You could then call that immediately after a
successful DTLSv1_listen() call. Obviously we'd have to change the dgram
BIO to use recvmsg for this to work.

Matt


From uri at ll.mit.edu  Tue Jan 16 23:32:46 2018
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Tue, 16 Jan 2018 18:32:46 -0500
Subject: [openssl-dev] [EXTERNAL] Re: PKCS12 safecontents bag type
 deviation from spec
In-Reply-To: <1516131071.9330.13.camel@sandia.gov>
References: <92C69AC3-A89E-405D-814E-D4B0DE024666@akamai.com>
 <1516131071.9330.13.camel@sandia.gov>
Message-ID: <86D8D642-1BBD-46F6-8086-90682C88CC3F@ll.mit.edu>

I think the change is justified.
?
Regards,
Uri

> On Jan 16, 2018, at 14:31, Sands, Daniel <dnsands at sandia.gov> wrote:
> 
> On Tue, 2018-01-16 at 14:50 +0000, Salz, Rich via openssl-dev wrote:
>> OpenSSL defines it as a SET OF and the spec says it?s a SEQUENCE
>> OF.  Ouch!  Will that cause interop problems if we change it?  (I
>> don?t remember the DER encoding rules)
>> 
>> 
>> 
> 
> Well, a SEQUENCE uses tag 16 while a SET uses tag 17, according to a
> quick reference I found.  So that could be an interoperability concern.
> But maybe this is the first actual use of nested safecontents, since
> this difference flew under the radar for so long :)
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180116/2ec75402/attachment.html>

From tmraz at redhat.com  Wed Jan 17 08:14:15 2018
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 17 Jan 2018 09:14:15 +0100
Subject: [openssl-dev] [EXTERNAL] Re: PKCS12 safecontents bag type
 deviation from spec
In-Reply-To: <1516131071.9330.13.camel@sandia.gov>
References: <92C69AC3-A89E-405D-814E-D4B0DE024666@akamai.com>
 <1516131071.9330.13.camel@sandia.gov>
Message-ID: <1516176855.3312.3.camel@redhat.com>

On Tue, 2018-01-16 at 19:31 +0000, Sands, Daniel wrote:
> On Tue, 2018-01-16 at 14:50 +0000, Salz, Rich via openssl-dev wrote:
> > OpenSSL defines it as a SET OF and the spec says it?s a SEQUENCE
> > OF.  Ouch!  Will that cause interop problems if we change it?  (I
> > don?t remember the DER encoding rules)
> > 
> > 
> > 
> 
> Well, a SEQUENCE uses tag 16 while a SET uses tag 17, according to a
> quick reference I found.  So that could be an interoperability
> concern.
>  But maybe this is the first actual use of nested safecontents, since
> this difference flew under the radar for so long :)

Would it be possible to allow for loading the safecontents bag with
both correct and incorrect tag? But we should always write the correct
one.

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]


From mcr at sandelman.ca  Wed Jan 17 16:34:45 2018
From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 17 Jan 2018 11:34:45 -0500
Subject: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)
In-Reply-To: <fd968187-1537-ea93-c797-f6e3ad700eaa@openssl.org>
References: <24932.1515179901@obiwan.sandelman.ca>
 <17541.1516116727@obiwan.sandelman.ca>
 <ada89d1a-f4a7-ecb0-ef31-f2c8e4d1905b@openssl.org>
 <13999.1516131878@obiwan.sandelman.ca>
 <fd968187-1537-ea93-c797-f6e3ad700eaa@openssl.org>
Message-ID: <29401.1516206885@obiwan.sandelman.ca>


Matt Caswell <matt at openssl.org> wrote:
    >> Matt Caswell <matt at openssl.org> wrote: >> a) when the existing FD is
    >> connect(2) any future traffic to the bound >> port will get rejected
    >> with no port.  So the application really has to >> open a new socket
    >> first.  The application can do this two ways: it can >> open a new
    >> socket on which to receive new connections, or it can open >> a new
    >> socket on which to communicate with the new client.  The second >>
    >> method is better for reason (b) below.  Either way, it socket to >>
    >> communicate with the client needs to be bind(2) to the address that >>
    >> the client used to communicate with the server, and DTLSv1_listen() >>
    >> didn't collect or return that information.
    >>
    >> > The second way is what is intended.
    >>
    >> Unfortunately, there remains a race condition because we have to call
    >> bind() before connect() on the new socket.  Under load, if a packet is
    >> received between the bind() and the connect(), it might go onto the
    >> wrong socket queue. So some packets that could have been processed
    >> will get dropped and have to be retransmitted by the client.

    > This seems like a non-issue to me. At this point in the handshake the
    > client will have sent its ClientHello and won't progress until it gets
    > the server's flight back (ServerHello etc), i.e. in the vast majority
    > of cases it won't be sending anything.

*That* client will be waiting, but other clients may be sending new ClientHello
messages (with or without cookies).

    >> The address of the remote client is returned ("getpeername()") by
    >> DTLSv1_listen().  That's all that recvfrom() gives you.
    >>
    >> recvfrom() was a reasonable API for SunOS 3.x machines with a single
    >> 10Mb/s interface with a single IPv4 address.  I loved all that at the
    >> time...  But it doesn't work that well when we might have a dozen
    >> different kind of IPv6 addresses on each virtual interface.
    >>
    >> The address that I'm talking about needing is the one the remote
    >> client used to reach us.  That's the destination IP of the incoming
    >> packet ("getsockname()" in TCP speak).

    > Ahhh....its the *server's* address you are after. This requirement
    > seems more reasonable. I think the API is designed to expect you to
    > only bind to a single IP. I'd be interested in Richard Levitte's
    > opinion on this.

okay.
binding to a single IP is not scalable in many applications.

    > It seems like a fairly simple solution could solve this. Currently we
    > have BIO_dgram_get_peer() which returns the peer's address for the last
    > message read from a BIO. You could imagine a new call being introduced
    > to get our own address. You could then call that immediately after a
    > successful DTLSv1_listen() call. Obviously we'd have to change the
    > dgram BIO to use recvmsg for this to work.

That's here:
       https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c
       https://github.com/mcr/openssl/commit/50692219afe92762e85338b8d947e7ac732d2cde
and:   https://github.com/mcr/openssl/commit/bb6f6b2cc860f25eb2b08aa109d1c7dc9ea94323


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180117/474faa3b/attachment.sig>

From psteuer at mail.de  Wed Jan 17 18:04:26 2018
From: psteuer at mail.de (Patrick Steuer)
Date: Wed, 17 Jan 2018 19:04:26 +0100
Subject: [openssl-dev] evp cipher/digest - add alternative to
	init-update-final interface
Message-ID: <d8ad246e-3cc8-0ab7-1e30-e8ec0b3ba0bf@mail.de>

libcrypto's interface for ciphers and digests implements a flexible
init-update(s)-final calling sequence that supports streaming of
arbitrary sized message chunks.

Said flexibility comes at a price in the "non-streaming" case: The
operation must be "artificially" split between update/final. This
leads to more functions than necessary needing to be called to
process a single paket (user errors). It is also a small paket
performance problem for (possibly engine provided) hardware
implementations for which it enforces a superfluous call to a
coprocessor or adapter.

libssl currently solves the problem, e.g for tls 1.2 aes-gcm record
layer encryption by passing additional context information via the
control interface and calling EVP_Cipher (undocumented, no engine
support. The analoguously named, undocumented EVP_Digest is just an
init-update-final wrapper). The same would be possible for tls 1.3
pakets (it is currently implemented using init-update-final and
performs worse than tls 1.2 record encryption on some s390 hardware).

I would suggest to add (engine supported) interfaces that can process a
paket with 2 calls (i.e. init-enc/dec/hash), at least for crypto
primitives that are often used in a non-streaming context, like aead
constructions in modern tls (This would also make it possible to move
tls specific code like nonce setup to libssl. Such interfaces already
exist in boringssl[1] and libressl[2]).

What do you think ?

Best,
Patrick

[1] 
https://commondatastorage.googleapis.com/chromium-boringssl-docs/aead.h.html
[2] http://man.openbsd.org/EVP_AEAD_CTX_init

From bkaduk at akamai.com  Wed Jan 17 20:56:46 2018
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Wed, 17 Jan 2018 14:56:46 -0600
Subject: [openssl-dev] evp cipher/digest - add alternative to
 init-update-final interface
In-Reply-To: <d8ad246e-3cc8-0ab7-1e30-e8ec0b3ba0bf@mail.de>
References: <d8ad246e-3cc8-0ab7-1e30-e8ec0b3ba0bf@mail.de>
Message-ID: <2fe3f984-b91b-6209-5ce8-82bc5463b463@akamai.com>

On 01/17/2018 12:04 PM, Patrick Steuer wrote:
> libcrypto's interface for ciphers and digests implements a flexible
> init-update(s)-final calling sequence that supports streaming of
> arbitrary sized message chunks.
>
> Said flexibility comes at a price in the "non-streaming" case: The
> operation must be "artificially" split between update/final. This
> leads to more functions than necessary needing to be called to
> process a single paket (user errors). It is also a small paket
> performance problem for (possibly engine provided) hardware
> implementations for which it enforces a superfluous call to a
> coprocessor or adapter.
>
> libssl currently solves the problem, e.g for tls 1.2 aes-gcm record
> layer encryption by passing additional context information via the
> control interface and calling EVP_Cipher (undocumented, no engine
> support. The analoguously named, undocumented EVP_Digest is just an
> init-update-final wrapper). The same would be possible for tls 1.3
> pakets (it is currently implemented using init-update-final and
> performs worse than tls 1.2 record encryption on some s390 hardware).
>
> I would suggest to add (engine supported) interfaces that can process a
> paket with 2 calls (i.e. init-enc/dec/hash), at least for crypto
> primitives that are often used in a non-streaming context, like aead
> constructions in modern tls (This would also make it possible to move
> tls specific code like nonce setup to libssl. Such interfaces already
> exist in boringssl[1] and libressl[2]).
>
> What do you think ?

The one-shot EVP_DigestSign() and EVP_DigestVerify() APIs were added to
support the PureEdDSA algorithm, which is incapable of performing
init/update/final signatures.? That seems like precedent for adding such
APIs for the other types of EVP functionality, though getting a
non-wrapper implementation that actually allows ENGINE implementations
would be some amount of work.

-Ben

From matt at openssl.org  Wed Jan 17 23:54:44 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 17 Jan 2018 23:54:44 +0000
Subject: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)
In-Reply-To: <29401.1516206885@obiwan.sandelman.ca>
References: <24932.1515179901@obiwan.sandelman.ca>
 <17541.1516116727@obiwan.sandelman.ca>
 <ada89d1a-f4a7-ecb0-ef31-f2c8e4d1905b@openssl.org>
 <13999.1516131878@obiwan.sandelman.ca>
 <fd968187-1537-ea93-c797-f6e3ad700eaa@openssl.org>
 <29401.1516206885@obiwan.sandelman.ca>
Message-ID: <aa697c37-9b5a-8d3d-17c2-7e34fb263149@openssl.org>



On 17/01/18 16:34, Michael Richardson wrote:
> 
> Matt Caswell <matt at openssl.org> wrote:
>     >> Matt Caswell <matt at openssl.org> wrote: >> a) when the existing FD is
>     >> connect(2) any future traffic to the bound >> port will get rejected
>     >> with no port.  So the application really has to >> open a new socket
>     >> first.  The application can do this two ways: it can >> open a new
>     >> socket on which to receive new connections, or it can open >> a new
>     >> socket on which to communicate with the new client.  The second >>
>     >> method is better for reason (b) below.  Either way, it socket to >>
>     >> communicate with the client needs to be bind(2) to the address that >>
>     >> the client used to communicate with the server, and DTLSv1_listen() >>
>     >> didn't collect or return that information.
>     >>
>     >> > The second way is what is intended.
>     >>
>     >> Unfortunately, there remains a race condition because we have to call
>     >> bind() before connect() on the new socket.  Under load, if a packet is
>     >> received between the bind() and the connect(), it might go onto the
>     >> wrong socket queue. So some packets that could have been processed
>     >> will get dropped and have to be retransmitted by the client.
> 
>     > This seems like a non-issue to me. At this point in the handshake the
>     > client will have sent its ClientHello and won't progress until it gets
>     > the server's flight back (ServerHello etc), i.e. in the vast majority
>     > of cases it won't be sending anything.
> 
> *That* client will be waiting, but other clients may be sending new ClientHello
> messages (with or without cookies).

So how does your refactor solve this issue? AFAICT this also just does a
bind then connect:

+
if(bind(rfd,BIO_ADDR_sockaddr(ouraddr),BIO_ADDR_sockaddr_size(ouraddr))
!= 0){
 +      goto end;
 +    }
 +
if(connect(rfd,BIO_ADDR_sockaddr(client),BIO_ADDR_sockaddr_size(client))
!= 0) {
 +      goto end;
 +    }

Doesn't this suffer from the same problem? i.e. packets could arrive
from other clients between the bind and connect.

Matt

From pwalten at au1.ibm.com  Thu Jan 18 01:37:29 2018
From: pwalten at au1.ibm.com (Peter Waltenberg)
Date: Thu, 18 Jan 2018 11:37:29 +1000
Subject: [openssl-dev] evp cipher/digest - add alternative
 to	init-update-final interface
In-Reply-To: <d8ad246e-3cc8-0ab7-1e30-e8ec0b3ba0bf@mail.de>
References: <d8ad246e-3cc8-0ab7-1e30-e8ec0b3ba0bf@mail.de>
Message-ID: <OF43BB2F4F.0D3DF25E-ON00258219.0008A50B-4A258219.00093FCF@notes.na.collabserv.com>

Or just add another EVP_CIPHER_CTX_ctrl() option (EVP_CTRL_CIPHER_ONE_SHOT 
or similar.) and handle it the way CCM does now and finish the operation 
on the first data update.

That doesn't require a new API and would probably simplify some existing 
code.

Peter




From:   Patrick Steuer <psteuer at mail.de>
To:     openssl-dev <openssl-dev at openssl.org>
Date:   18/01/2018 04:10
Subject:        [openssl-dev] evp cipher/digest - add alternative to 
init-update-final interface
Sent by:        "openssl-dev" <openssl-dev-bounces at openssl.org>



libcrypto's interface for ciphers and digests implements a flexible
init-update(s)-final calling sequence that supports streaming of
arbitrary sized message chunks.

Said flexibility comes at a price in the "non-streaming" case: The
operation must be "artificially" split between update/final. This
leads to more functions than necessary needing to be called to
process a single paket (user errors). It is also a small paket
performance problem for (possibly engine provided) hardware
implementations for which it enforces a superfluous call to a
coprocessor or adapter.

libssl currently solves the problem, e.g for tls 1.2 aes-gcm record
layer encryption by passing additional context information via the
control interface and calling EVP_Cipher (undocumented, no engine
support. The analoguously named, undocumented EVP_Digest is just an
init-update-final wrapper). The same would be possible for tls 1.3
pakets (it is currently implemented using init-update-final and
performs worse than tls 1.2 record encryption on some s390 hardware).

I would suggest to add (engine supported) interfaces that can process a
paket with 2 calls (i.e. init-enc/dec/hash), at least for crypto
primitives that are often used in a non-streaming context, like aead
constructions in modern tls (This would also make it possible to move
tls specific code like nonce setup to libssl. Such interfaces already
exist in boringssl[1] and libressl[2]).

What do you think ?

Best,
Patrick

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__commondatastorage.googleapis.com_chromium-2Dboringssl-2Ddocs_aead.h.html&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ&s=upMfA8eZGxh6kmIwqjO38Chm2MNi_BocHjrm84jCvOU&e=

[2] 
https://urldefense.proofpoint.com/v2/url?u=http-3A__man.openbsd.org_EVP-5FAEAD-5FCTX-5Finit&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ&s=YXrque0c5mOqsKzVMjt2T5m4mIcgo3GVThIqnGLJeRo&e=

-- 
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ&s=-TsrGPSFfFkhWasxuHDt19pNsDGsEW3BQp19rT507Xw&e=






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180118/cb641d1b/attachment.html>

From psteuer at mail.de  Thu Jan 18 16:34:05 2018
From: psteuer at mail.de (Patrick Steuer)
Date: Thu, 18 Jan 2018 17:34:05 +0100
Subject: [openssl-dev] evp cipher/digest - add alternative to
 init-update-final interface
In-Reply-To: <OF43BB2F4F.0D3DF25E-ON00258219.0008A50B-4A258219.00093FCF@notes.na.collabserv.com>
References: <d8ad246e-3cc8-0ab7-1e30-e8ec0b3ba0bf@mail.de>
 <OF43BB2F4F.0D3DF25E-ON00258219.0008A50B-4A258219.00093FCF@notes.na.collabserv.com>
Message-ID: <be5fc9df-f244-feb7-70dd-8bb211ef44f5@mail.de>

On 01/18/2018 02:37 AM, Peter Waltenberg wrote:
> Or just add another EVP_CIPHER_CTX_ctrl() option (EVP_CTRL_CIPHER_ONE_SHOT
> or similar.) and handle it the way CCM does now and finish the operation
> on the first data update.
> 
> That doesn't require a new API and would probably simplify some existing
> code.

Ctrls for 1-shot aead paket processing like in tls 1.2 would be the 
easiest solution for tls 1.3 pakets and i agree it could also be 
extended to the general case.

Though aead is in some sense more than a cipher mode of operation. 
Providing a dedicated api would have some advantages but i see that 
maybe i reopen a discussion:

"We are also evaluating the following new features. -New AEAD API [...]"
https://www.openssl.org/policies/roadmap.html#forthcoming

Was this already evaluated? If yes, what was the result ?

From mcr at sandelman.ca  Thu Jan 18 21:00:22 2018
From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 18 Jan 2018 16:00:22 -0500
Subject: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)
In-Reply-To: <aa697c37-9b5a-8d3d-17c2-7e34fb263149@openssl.org>
References: <24932.1515179901@obiwan.sandelman.ca>
 <17541.1516116727@obiwan.sandelman.ca>
 <ada89d1a-f4a7-ecb0-ef31-f2c8e4d1905b@openssl.org>
 <13999.1516131878@obiwan.sandelman.ca>
 <fd968187-1537-ea93-c797-f6e3ad700eaa@openssl.org>
 <29401.1516206885@obiwan.sandelman.ca>
 <aa697c37-9b5a-8d3d-17c2-7e34fb263149@openssl.org>
Message-ID: <16081.1516309222@obiwan.sandelman.ca>


Matt Caswell <matt at openssl.org> wrote:
    >> Matt Caswell <matt at openssl.org> wrote:
    >> >> Matt Caswell <matt at openssl.org> wrote: >> a) when the existing FD is
    >> >> connect(2) any future traffic to the bound >> port will get rejected
    >> >> with no port.  So the application really has to >> open a new socket
    >> >> first.  The application can do this two ways: it can >> open a new
    >> >> socket on which to receive new connections, or it can open >> a new
    >> >> socket on which to communicate with the new client.  The second >>
    >> >> method is better for reason (b) below.  Either way, it socket to >>
    >> >> communicate with the client needs to be bind(2) to the address that >>
    >> >> the client used to communicate with the server, and DTLSv1_listen() >>
    >> >> didn't collect or return that information.
    >> >>
    >> >> > The second way is what is intended.
    >> >>
    >> >> Unfortunately, there remains a race condition because we have to call
    >> >> bind() before connect() on the new socket.  Under load, if a packet is
    >> >> received between the bind() and the connect(), it might go onto the
    >> >> wrong socket queue. So some packets that could have been processed
    >> >> will get dropped and have to be retransmitted by the client.
    >>
    >> > This seems like a non-issue to me. At this point in the handshake the
    >> > client will have sent its ClientHello and won't progress until it gets
    >> > the server's flight back (ServerHello etc), i.e. in the vast majority
    >> > of cases it won't be sending anything.
    >>
    >> *That* client will be waiting, but other clients may be sending new ClientHello
    >> messages (with or without cookies).

    > So how does your refactor solve this issue? AFAICT this also just does a
    > bind then connect:

My refactor does not solve it. I'm noting that this is still an issue.

It's not solvable unless the kernel can do both operations at the same time,
for which there isn't a standard call (nor a non-standard one).
If we could punt segments between BIOs easily, then we could deal with the
problem, but I don't think it's worth solving.


    > if(bind(rfd,BIO_ADDR_sockaddr(ouraddr),BIO_ADDR_sockaddr_size(ouraddr))
    > != 0){
    > +      goto end;
    > +    }
    > +
    > if(connect(rfd,BIO_ADDR_sockaddr(client),BIO_ADDR_sockaddr_size(client))
    > != 0) {
    > +      goto end;
    > +    }

    > Doesn't this suffer from the same problem? i.e. packets could arrive
    > from other clients between the bind and connect.

Yes.

This is in contrast this situation to the original problem with connect()'ing
the socket which is given to DTLSv1_listen(). That socket has lots of time
between the two points in which to accumulate new connection requests.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180118/2d1a1533/attachment.sig>

From kurt at roeckx.be  Fri Jan 19 00:19:49 2018
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 19 Jan 2018 01:19:49 +0100
Subject: [openssl-dev] evp cipher/digest - add alternative to
 init-update-final interface
In-Reply-To: <be5fc9df-f244-feb7-70dd-8bb211ef44f5@mail.de>
References: <d8ad246e-3cc8-0ab7-1e30-e8ec0b3ba0bf@mail.de>
 <OF43BB2F4F.0D3DF25E-ON00258219.0008A50B-4A258219.00093FCF@notes.na.collabserv.com>
 <be5fc9df-f244-feb7-70dd-8bb211ef44f5@mail.de>
Message-ID: <20180119001949.GA14606@roeckx.be>

On Thu, Jan 18, 2018 at 05:34:05PM +0100, Patrick Steuer wrote:
> 
> Though aead is in some sense more than a cipher mode of operation. Providing
> a dedicated api would have some advantages but i see that maybe i reopen a
> discussion:
> 
> "We are also evaluating the following new features. -New AEAD API [...]"
> https://www.openssl.org/policies/roadmap.html#forthcoming
> 
> Was this already evaluated? If yes, what was the result ?

Nobody has had time for this, feel free to make a proposal.


Kurt


From matt at openssl.org  Fri Jan 19 11:20:40 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 19 Jan 2018 11:20:40 +0000
Subject: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)
In-Reply-To: <29401.1516206885@obiwan.sandelman.ca>
References: <24932.1515179901@obiwan.sandelman.ca>
 <17541.1516116727@obiwan.sandelman.ca>
 <ada89d1a-f4a7-ecb0-ef31-f2c8e4d1905b@openssl.org>
 <13999.1516131878@obiwan.sandelman.ca>
 <fd968187-1537-ea93-c797-f6e3ad700eaa@openssl.org>
 <29401.1516206885@obiwan.sandelman.ca>
Message-ID: <3e445ce0-be9c-7130-f200-59864e12d9e6@openssl.org>



On 17/01/18 16:34, Michael Richardson wrote:
> 
>     > It seems like a fairly simple solution could solve this. Currently we
>     > have BIO_dgram_get_peer() which returns the peer's address for the last
>     > message read from a BIO. You could imagine a new call being introduced
>     > to get our own address. You could then call that immediately after a
>     > successful DTLSv1_listen() call. Obviously we'd have to change the
>     > dgram BIO to use recvmsg for this to work.
> 
> That's here:
>        https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c
>        https://github.com/mcr/openssl/commit/50692219afe92762e85338b8d947e7ac732d2cde
> and:   https://github.com/mcr/openssl/commit/bb6f6b2cc860f25eb2b08aa109d1c7dc9ea94323

Please raise a separate PR for this work. It *must* be portable though
and work across all our platforms (e.g. including VisualC etc). My
suggestion is that your BIO_CTRL_DGRAM_GET_ADDR/BIO_CTRL_DGRAM_SET_ADDR
ctrls should return an error on platforms that we don't know we can
support, i.e. attempt to detect (at compile time) whether we are on a
platform that we know has the required system calls - if we are then use
them, otherwise we do things the old way.

Note that stuff like this is problematic:

    char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
in_pktinfo))];

The "attribute" is compiler specific and not something we can rely on to
be available. Additionally "CMSG_SPACE" is probably not portable, and in
any case may not evaluate to a compile time constant (according to the
man page), so this is not C90 (which is a requirement for OpenSSL
submissions).

I suggest you Configure with the "--strict-warnings" option which will
probably complain about some of this stuff.

Please also make sure we have suitable documentation and ideally tests too.

Once this PR is in (assuming it gets accepted), then you can look at
what remains of your original PR and see if it makes sense to raise new
PRs to bring the rest of it in.

Matt


From mcr at sandelman.ca  Fri Jan 19 16:32:35 2018
From: mcr at sandelman.ca (Michael Richardson)
Date: Fri, 19 Jan 2018 11:32:35 -0500
Subject: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)
In-Reply-To: <3e445ce0-be9c-7130-f200-59864e12d9e6@openssl.org>
References: <24932.1515179901@obiwan.sandelman.ca>
 <17541.1516116727@obiwan.sandelman.ca>
 <ada89d1a-f4a7-ecb0-ef31-f2c8e4d1905b@openssl.org>
 <13999.1516131878@obiwan.sandelman.ca>
 <fd968187-1537-ea93-c797-f6e3ad700eaa@openssl.org>
 <29401.1516206885@obiwan.sandelman.ca>
 <3e445ce0-be9c-7130-f200-59864e12d9e6@openssl.org>
Message-ID: <10728.1516379555@obiwan.sandelman.ca>

Matt Caswell <matt at openssl.org> wrote:
    > Please raise a separate PR for this work. It *must* be portable though
    > and work across all our platforms (e.g. including VisualC etc). My
    > suggestion is that your BIO_CTRL_DGRAM_GET_ADDR/BIO_CTRL_DGRAM_SET_ADDR
    > ctrls should return an error on platforms that we don't know we can
    > support, i.e. attempt to detect (at compile time) whether we are on a
    > platform that we know has the required system calls - if we are then use
    > them, otherwise we do things the old way.

    > Note that stuff like this is problematic:

    > char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
    > in_pktinfo))];

    > The "attribute" is compiler specific and not something we can rely on to
    > be available. Additionally "CMSG_SPACE" is probably not portable, and in
    > any case may not evaluate to a compile time constant (according to the
    > man page), so this is not C90 (which is a requirement for OpenSSL
    > submissions).

Understood.
I think that CMSG_SPACE might be in the POSIX spec, but I'll double check.

What do you suggest I do for the IPv4 stuff, which has no POSIX standard?
A bunch of #ifdef on OS definitions?

    > Once this PR is in (assuming it gets accepted), then you can look at
    > what remains of your original PR and see if it makes sense to raise new
    > PRs to bring the rest of it in.

Roger. Wilco.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


From matt at openssl.org  Fri Jan 19 16:37:17 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 19 Jan 2018 16:37:17 +0000
Subject: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)
In-Reply-To: <10728.1516379555@obiwan.sandelman.ca>
References: <24932.1515179901@obiwan.sandelman.ca>
 <17541.1516116727@obiwan.sandelman.ca>
 <ada89d1a-f4a7-ecb0-ef31-f2c8e4d1905b@openssl.org>
 <13999.1516131878@obiwan.sandelman.ca>
 <fd968187-1537-ea93-c797-f6e3ad700eaa@openssl.org>
 <29401.1516206885@obiwan.sandelman.ca>
 <3e445ce0-be9c-7130-f200-59864e12d9e6@openssl.org>
 <10728.1516379555@obiwan.sandelman.ca>
Message-ID: <addd8d96-1ff4-58b0-f4d2-1d5a0be00722@openssl.org>



On 19/01/18 16:32, Michael Richardson wrote:
> Matt Caswell <matt at openssl.org> wrote:
>     > Please raise a separate PR for this work. It *must* be portable though
>     > and work across all our platforms (e.g. including VisualC etc). My
>     > suggestion is that your BIO_CTRL_DGRAM_GET_ADDR/BIO_CTRL_DGRAM_SET_ADDR
>     > ctrls should return an error on platforms that we don't know we can
>     > support, i.e. attempt to detect (at compile time) whether we are on a
>     > platform that we know has the required system calls - if we are then use
>     > them, otherwise we do things the old way.
> 
>     > Note that stuff like this is problematic:
> 
>     > char __attribute__((aligned(8))) chdr[CMSG_SPACE(sizeof(struct
>     > in_pktinfo))];
> 
>     > The "attribute" is compiler specific and not something we can rely on to
>     > be available. Additionally "CMSG_SPACE" is probably not portable, and in
>     > any case may not evaluate to a compile time constant (according to the
>     > man page), so this is not C90 (which is a requirement for OpenSSL
>     > submissions).
> 
> Understood.
> I think that CMSG_SPACE might be in the POSIX spec, but I'll double check.
> 
> What do you suggest I do for the IPv4 stuff, which has no POSIX standard?
> A bunch of #ifdef on OS definitions?

If its non portable and we're not already using it then that's the
probably the best we can do. We should try and provide some sensible
fallback wherever possible. Or if not possible it shouldn't break
anything that already works.

Matt

From rsalz at akamai.com  Fri Jan 19 17:34:57 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 19 Jan 2018 17:34:57 +0000
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
Message-ID: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>

There?s a new blog post at 
    https://www.openssl.org/blog/blog/2018/01/18/f2f-london/

It contains some important policy changes we decided at our meeting last month.  This includes:
    - Closing the openssl-dev mailing list; use GitHub for issues
    - New mailing list openssl-project for project discussions
    - New policy for accepting crypto algorithms, formats, and protocols.
    - .. several others

Please read the posting; the changes described in it affect everyone who uses OpenSSL.  Thanks for your interest, and all your efforts to help improve the project!




From uri at ll.mit.edu  Fri Jan 19 17:40:42 2018
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Fri, 19 Jan 2018 17:40:42 +0000
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
Message-ID: <C5056D39-1002-4E58-A9EC-61F7AEA21B7B@ll.mit.edu>

It appears to me that you could use openssl-dev instead of openssl-project, saving cycles on killing one and creating the other.

--
Regards,
Uri Blumenthal

On 1/19/18, 12:35, "openssl-dev on behalf of Salz, Rich via openssl-dev" <openssl-dev-bounces at openssl.org on behalf of openssl-dev at openssl.org> wrote:

    There?s a new blog post at 
        https://www.openssl.org/blog/blog/2018/01/18/f2f-london/
    
    It contains some important policy changes we decided at our meeting last month.  This includes:
        - Closing the openssl-dev mailing list; use GitHub for issues
        - New mailing list openssl-project for project discussions
        - New policy for accepting crypto algorithms, formats, and protocols.
        - .. several others
    
    Please read the posting; the changes described in it affect everyone who uses OpenSSL.  Thanks for your interest, and all your efforts to help improve the project!
    
    
    
    -- 
    openssl-dev mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180119/d8cc677d/attachment.bin>

From rsalz at akamai.com  Fri Jan 19 17:51:57 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 19 Jan 2018 17:51:57 +0000
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <C5056D39-1002-4E58-A9EC-61F7AEA21B7B@ll.mit.edu>
References: <C5056D39-1002-4E58-A9EC-61F7AEA21B7B@ll.mit.edu>
Message-ID: <9B3BF7BD-5596-4E5A-986B-BC7BFD0C78B8@akamai.com>

? It appears to me that you could use openssl-dev instead of openssl-project, saving cycles on killing one and creating the other.
    
We discussed that, but it would be harder to ?undo? if things don?t work out, we wanted to make it very clear that this is a new way of operating, and openssl-project is a moderated list.  Make sense?


From uri at ll.mit.edu  Fri Jan 19 18:38:53 2018
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Fri, 19 Jan 2018 18:38:53 +0000
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <9B3BF7BD-5596-4E5A-986B-BC7BFD0C78B8@akamai.com>
References: <C5056D39-1002-4E58-A9EC-61F7AEA21B7B@ll.mit.edu>
 <9B3BF7BD-5596-4E5A-986B-BC7BFD0C78B8@akamai.com>
Message-ID: <AAD42C58-7FC9-4213-8F49-2F76E8E2C43F@ll.mit.edu>

On 1/19/18, 12:52, "Salz, Rich" <rsalz at akamai.com> wrote:

 >> It appears to me that you could use openssl-dev instead of openssl-project, saving cycles on killing
>> one and creating the other.
>
>  We discussed that, but it would be harder to ?undo? if things don?t work out, we wanted
>   to make it very clear that this is a new way of operating, and openssl-project is a
>   moderated list.  Make sense?

I don?t know. I?d still do as I said. But since you guys discussed it (i.e., debated this option), I?ll defer to your judgment.
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180119/65869ea4/attachment-0001.bin>

From hkario at redhat.com  Tue Jan 23 12:00:29 2018
From: hkario at redhat.com (Hubert Kario)
Date: Tue, 23 Jan 2018 13:00:29 +0100
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
Message-ID: <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com>

On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote:
> There?s a new blog post at 
>     https://www.openssl.org/blog/blog/2018/01/18/f2f-london/

> We decided to increase our use of GitHub. In addition to asking that all bug
> reports and enhancement requests be reported as issues, we now want all
> major code proposals to be discussed as issues before a large pull request
> shows up. This will let the community discuss the feature, offer input on
> design and such, before having code to look at. We hope this will let us
> all first look at the bigger picture, before getting bogged down in the
> weeds of line-by-line code reviews.

does that mean I have to subscribe to all notifications from the openssl 
github project to notice them? that's really suboptimal

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180123/f34baa5f/attachment.sig>

From beldmit at gmail.com  Tue Jan 23 12:27:10 2018
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 23 Jan 2018 15:27:10 +0300
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com>
Message-ID: <CADqLbzKpVj32Csk3izYmdz5vVWZuXvo8pK3R5xyVdfQiurwMig@mail.gmail.com>

Hello,

On Tue, Jan 23, 2018 at 3:00 PM, Hubert Kario <hkario at redhat.com> wrote:

> On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote:
> > There?s a new blog post at
> >     https://www.openssl.org/blog/blog/2018/01/18/f2f-london/
>
> > We decided to increase our use of GitHub. In addition to asking that all
> bug
> > reports and enhancement requests be reported as issues, we now want all
> > major code proposals to be discussed as issues before a large pull
> request
> > shows up. This will let the community discuss the feature, offer input on
> > design and such, before having code to look at. We hope this will let us
> > all first look at the bigger picture, before getting bogged down in the
> > weeds of line-by-line code reviews.
>
> does that mean I have to subscribe to all notifications from the openssl
> github project to notice them? that's really suboptimal
>

Totally agree.


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180123/d8c4045b/attachment.html>

From rsalz at akamai.com  Tue Jan 23 14:22:13 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 23 Jan 2018 14:22:13 +0000
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com>
Message-ID: <8A96BA0F-A92C-45AE-A780-A84597827C4B@akamai.com>

You should be able to just watch the openssl repo (the eyeball/watch notice in the upper-right side)

On 1/23/18, 7:00 AM, "Hubert Kario" <hkario at redhat.com> wrote:

    On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev wrote:
    > There?s a new blog post at 
    >     https://www.openssl.org/blog/blog/2018/01/18/f2f-london/
    
    > We decided to increase our use of GitHub. In addition to asking that all bug
    > reports and enhancement requests be reported as issues, we now want all
    > major code proposals to be discussed as issues before a large pull request
    > shows up. This will let the community discuss the feature, offer input on
    > design and such, before having code to look at. We hope this will let us
    > all first look at the bigger picture, before getting bogged down in the
    > weeds of line-by-line code reviews.
    
    does that mean I have to subscribe to all notifications from the openssl 
    github project to notice them? that's really suboptimal
    
    -- 
    Regards,
    Hubert Kario
    Senior Quality Engineer, QE BaseOS Security team
    Web: www.cz.redhat.com
    Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic


From phpdev at ehrhardt.nl  Tue Jan 23 14:26:47 2018
From: phpdev at ehrhardt.nl (Jan Ehrhardt)
Date: Tue, 23 Jan 2018 15:26:47 +0100
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
Message-ID: <a9he6dt1di748pmo2rftd2hgig278gtfpv@4ax.com>

Salz, Rich via open	ssl-dev in gmane.comp.encryption.openssl.devel
(Fri, 19 Jan 2018 17:34:57 +0000):
>    - New mailing list openssl-project for project discussions

For the lovers of NNTP: openssl-project has been added to news.gmane.org
as gmane.comp.encryption.openssl.project as readonly list.
-- 
Jan


From hkario at redhat.com  Tue Jan 23 14:31:17 2018
From: hkario at redhat.com (Hubert Kario)
Date: Tue, 23 Jan 2018 15:31:17 +0100
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <8A96BA0F-A92C-45AE-A780-A84597827C4B@akamai.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com>
 <8A96BA0F-A92C-45AE-A780-A84597827C4B@akamai.com>
Message-ID: <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>

On Tuesday, 23 January 2018 15:22:13 CET Salz, Rich wrote:
> You should be able to just watch the openssl repo (the eyeball/watch notice
> in the upper-right side)

that's what I was talking about

this feature sends notifications about _all_ conversations happening.

> On 1/23/18, 7:00 AM, "Hubert Kario" <hkario at redhat.com> wrote:
> 
>     On Friday, 19 January 2018 18:34:57 CET Salz, Rich via openssl-dev
> wrote:
>     > There?s a new blog post at 
>     > 
>     >     https://www.openssl.org/blog/blog/2018/01/18/f2f-london/
> 
>     
> 
>     > We decided to increase our use of GitHub. In addition to asking that
>     > all bug
>     > reports and enhancement requests be reported as issues, we
>     > now want all major code proposals to be discussed as issues before a
>     > large pull request shows up. This will let the community discuss the
>     > feature, offer input on design and such, before having code to look
>     > at. We hope this will let us all first look at the bigger picture,
>     > before getting bogged down in the weeds of line-by-line code reviews.
> 
>     
>     does that mean I have to subscribe to all notifications from the openssl
> 
> github project to notice them? that's really suboptimal
>     
>     -- 
>     Regards,
>     Hubert Kario
>     Senior Quality Engineer, QE BaseOS Security team
>     Web: www.cz.redhat.com
>     Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
> 


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180123/0852b552/attachment.sig>

From rsalz at akamai.com  Tue Jan 23 14:36:26 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 23 Jan 2018 14:36:26 +0000
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <1782817.M3ba5i8hfn@pintsize.usersys.redhat.com>
 <8A96BA0F-A92C-45AE-A780-A84597827C4B@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
Message-ID: <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>

? this feature sends notifications about _all_ conversations happening.
    
For me, I get the actual comments that are posted.  Don?t you?  On the mailing list, you have to explicitly mark/junk conversation threads in your mail program.  You would still have to do that here.

I don?t understand what you see as different?


From rsalz at akamai.com  Tue Jan 23 14:38:14 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 23 Jan 2018 14:38:14 +0000
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <a9he6dt1di748pmo2rftd2hgig278gtfpv@4ax.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <a9he6dt1di748pmo2rftd2hgig278gtfpv@4ax.com>
Message-ID: <8C351E82-600B-487E-AEF3-A3F42CD231D4@akamai.com>


?     For the lovers of NNTP: openssl-project has been added to news.gmane.org
    as gmane.comp.encryption.openssl.project as readonly list.
  
I will always have a fondness for NNTP :)  But that reminds me to nudge the other mailing list distributors, and update the website.  Thanks!


From hkario at redhat.com  Tue Jan 23 14:54:56 2018
From: hkario at redhat.com (Hubert Kario)
Date: Tue, 23 Jan 2018 15:54:56 +0100
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
Message-ID: <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>

On Tuesday, 23 January 2018 15:36:26 CET Salz, Rich wrote:
> ? this feature sends notifications about _all_ conversations happening.
>     
> For me, I get the actual comments that are posted.  Don?t you?

when I comment in an issue/PR or mark it as followed I'm getting only messages 
from that issue/PR

when I mark project as followed I'm getting messages from all issues and all 
PRs - likely dozens if not hundred messages a day

> On the
> mailing list, you have to explicitly mark/junk conversation threads in your
> mail program.  You would still have to do that here.
 
> I don?t understand what you see as different?

that marking a conversation as ignored and going to next one is two key 
combinations and less than a second, github ones require me to go to the web 
UI which is slow, and if I have to view the issue because subject is ambiguous 
it takes ten times as long as it does when using email

email clients are designed to handle hundreds to thousands of messages a day, 
Github UI isn't

or to put it other way: github notifications are perfect if you are directly 
involved in the project, they suck if you just want to keep tabs on an active 
project
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180123/82f4527b/attachment.sig>

From Matthias.St.Pierre at ncp-e.com  Tue Jan 23 14:59:29 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 23 Jan 2018 15:59:29 +0100
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
Message-ID: <441b80ce-bf32-59a4-f202-f3b71f72a061@ncp-e.com>

On 23.01.2018 15:54, Hubert Kario wrote:
> On Tuesday, 23 January 2018 15:36:26 CET Salz, Rich wrote:
>> ? this feature sends notifications about _all_ conversations happening.
>>     
>> For me, I get the actual comments that are posted.  Don?t you?
> when I comment in an issue/PR or mark it as followed I'm getting only messages 
> from that issue/PR
>
> when I mark project as followed I'm getting messages from all issues and all 
> PRs - likely dozens if not hundred messages a day

Have you checked Github > Settings > Emails > Email preferences ??
Maybe yours are set to "Receive all emails"?

My settings are as follows:

?????? ( )? Receive all emails, except those I unsubscribe from.

?????? (*) Only receive account related emails, and those I subscribe to.


From rsalz at akamai.com  Tue Jan 23 15:13:30 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 23 Jan 2018 15:13:30 +0000
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
Message-ID: <97C47A19-4E39-41FB-803A-15C9479B2B1F@akamai.com>

?  github ones require me to go to the web 
    UI which is slow

I am confused by that.  When someone posts an issue or comment, I get the text emailed to me.  Not just openssl, but all projects I watch.





From hkario at redhat.com  Tue Jan 23 15:39:59 2018
From: hkario at redhat.com (Hubert Kario)
Date: Tue, 23 Jan 2018 16:39:59 +0100
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <97C47A19-4E39-41FB-803A-15C9479B2B1F@akamai.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
 <97C47A19-4E39-41FB-803A-15C9479B2B1F@akamai.com>
Message-ID: <2024333.bmkDkyICYB@pintsize.usersys.redhat.com>

On Tuesday, 23 January 2018 16:13:30 CET Salz, Rich wrote:
> ?  github ones require me to go to the web 
>     UI which is slow
> 
> I am confused by that.  When someone posts an issue or comment, I get the
> text emailed to me.  Not just openssl, but all projects I watch.
 
ah, true, I have those disabled because I use the same account for both my 
personal and my work projects so no single email address is correct for them

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180123/95509aa3/attachment.sig>

From rsalz at akamai.com  Tue Jan 23 16:10:19 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 23 Jan 2018 16:10:19 +0000
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <2024333.bmkDkyICYB@pintsize.usersys.redhat.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
 <97C47A19-4E39-41FB-803A-15C9479B2B1F@akamai.com>
 <2024333.bmkDkyICYB@pintsize.usersys.redhat.com>
Message-ID: <82F497DD-21CF-4E03-B63F-F7316D647FB4@akamai.com>

? ah, true, I have those disabled because I use the same account for both my 
    personal and my work projects so no single email address is correct for them
    
At least we figured out the confusion!

I have no good answer other than subject line filtering and forwarding, sorry.


From levitte at openssl.org  Tue Jan 23 18:42:52 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 23 Jan 2018 19:42:52 +0100 (CET)
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <8C351E82-600B-487E-AEF3-A3F42CD231D4@akamai.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <a9he6dt1di748pmo2rftd2hgig278gtfpv@4ax.com>
 <8C351E82-600B-487E-AEF3-A3F42CD231D4@akamai.com>
Message-ID: <20180123.194252.749500207961038072.levitte@openssl.org>

In message <8C351E82-600B-487E-AEF3-A3F42CD231D4 at akamai.com> on Tue, 23 Jan 2018 14:38:14 +0000, "Salz, Rich via openssl-dev" <openssl-dev at openssl.org> said:

openssl-dev> 
openssl-dev> ?     For the lovers of NNTP: openssl-project has been added to news.gmane.org
openssl-dev>     as gmane.comp.encryption.openssl.project as readonly list.
openssl-dev>   
openssl-dev> I will always have a fondness for NNTP :)

...  except for the trashing of the database disk(s) back in the days
if you're running a server...  (I did)  (on VMS ;-))

But yeah, totally agree otherwise

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

From fw at deneb.enyo.de  Tue Jan 23 18:40:09 2018
From: fw at deneb.enyo.de (Florian Weimer)
Date: Tue, 23 Jan 2018 19:40:09 +0100
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <1825521.mmB0qapBzR@pintsize.usersys.redhat.com> (Hubert Kario's
 message of "Tue, 23 Jan 2018 15:54:56 +0100")
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
Message-ID: <87bmhk1ks6.fsf@mid.deneb.enyo.de>

* Hubert Kario:

> when I mark project as followed I'm getting messages from all issues
> and all PRs - likely dozens if not hundred messages a day

But isn't that the point?

My main concern with Github is that I have no record of my own
actions.  (Their single-account policy is also a problem for some of
us, but that is perhaps our own fault.)

From yun.jiang at realvnc.com  Tue Jan 23 21:45:12 2018
From: yun.jiang at realvnc.com (Yun Jiang)
Date: Tue, 23 Jan 2018 21:45:12 +0000
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
 crypto/objects/obj_dat.c
Message-ID: <b345caea6be54021b7a2e5482eaffdb2@realvnc.com>

The APIs defined in the file crypto/objects/obj_dat.c share some static global variables defined in the file without locking, which makes the APIs in this file not multi-thread safe even if the locking callbacks are set. In addition, the APIs in this file are also used by the other OpenSSL APIs, which makes the following OpenSSL documentation statement invalid (https://www.openssl.org/docs/man1.0.2/crypto/threads.html)


"OpenSSL can safely be used in multi-threaded applications provided that at least two callback functions are set, locking_function and threadid_func."


Is there any planning to fix this issue?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180123/e017b1b3/attachment.html>

From rsalz at akamai.com  Wed Jan 24 01:19:20 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Jan 2018 01:19:20 +0000
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
 crypto/objects/obj_dat.c
Message-ID: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>

  *   OpenSSL APIs, which makes the following OpenSSL documentation statement invalid (https://www.openssl.org/docs/man1.0.2/crypto/threads.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.0.2_crypto_threads.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o&s=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY&e=>)



  *   "OpenSSL can safely be used in multi-threaded applications provided that at least two callback functions are set, locking_function and threadid_func."



  *   Is there any planning to fix this issue?





Well, the most likely fix is to make the ?safely? wording be more vague, which I doubt you?ll like.  But I doubt anyone on the team has much interest in fixing 1.0.2 locking issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/bac798a1/attachment.html>

From pwalten at au1.ibm.com  Wed Jan 24 01:23:03 2018
From: pwalten at au1.ibm.com (Peter Waltenberg)
Date: Wed, 24 Jan 2018 11:23:03 +1000
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
 crypto/objects/obj_dat.c
In-Reply-To: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
References: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
Message-ID: <OFD4395139.95F7DCC3-ON0025821F.0007719C-4A25821F.0007F2B0@notes.na.collabserv.com>

It's also not that much of a problem in practice.. 
If you are using those API's you are adding new crypto. methods. Doing 
that after threading has started is not going to give good results with or 
without locking.

Peter




From:   "Salz, Rich via openssl-dev" <openssl-dev at openssl.org>
To:     "openssl-dev at openssl.org" <openssl-dev at openssl.org>
Date:   24/01/2018 11:19
Subject:        Re: [openssl-dev] About multi-thread unsafe for APIs 
defined in crypto/objects/obj_dat.c
Sent by:        "openssl-dev" <openssl-dev-bounces at openssl.org>



OpenSSL APIs, which makes the following OpenSSL documentation statement 
invalid (https://www.openssl.org/docs/man1.0.2/crypto/threads.html)
 
"OpenSSL can safely be used in multi-threaded applications provided that 
at least two callback functions are set, locking_function and 
threadid_func."
 
Is there any planning to fix this issue?
 
 
Well, the most likely fix is to make the ?safely? wording be more vague, 
which I doubt you?ll like.  But I doubt anyone on the team has much 
interest in fixing 1.0.2 locking issues.-- 
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs&s=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw&e=





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/4f908905/attachment-0001.html>

From yun.jiang at realvnc.com  Wed Jan 24 08:32:34 2018
From: yun.jiang at realvnc.com (Yun Jiang)
Date: Wed, 24 Jan 2018 08:32:34 +0000
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
 crypto/objects/obj_dat.c
In-Reply-To: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
References: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
Message-ID: <da67f587405a4c71ac389676e6067507@realvnc.com>

Thanks! Is this issue fixed in 1.1.0?

Yun

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-dev
Sent: 24 January 2018 01:19
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

?  OpenSSL APIs, which makes the following OpenSSL documentation statement invalid (https://www.openssl.org/docs/man1.0.2/crypto/threads.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.0.2_crypto_threads.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o&s=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY&e=>)


?  "OpenSSL can safely be used in multi-threaded applications provided that at least two callback functions are set, locking_function and threadid_func."


?  Is there any planning to fix this issue?





Well, the most likely fix is to make the ?safely? wording be more vague, which I doubt you?ll like.  But I doubt anyone on the team has much interest in fixing 1.0.2 locking issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/1de0a290/attachment.html>

From yun.jiang at realvnc.com  Wed Jan 24 12:37:48 2018
From: yun.jiang at realvnc.com (Yun Jiang)
Date: Wed, 24 Jan 2018 12:37:48 +0000
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
 crypto/objects/obj_dat.c
In-Reply-To: <OFD4395139.95F7DCC3-ON0025821F.0007719C-4A25821F.0007F2B0@notes.na.collabserv.com>
References: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
 <OFD4395139.95F7DCC3-ON0025821F.0007719C-4A25821F.0007F2B0@notes.na.collabserv.com>
Message-ID: <8406c9abc40049ae95613dcc9965a3aa@realvnc.com>

Thanks!

The problem is that I need to get a customized certificate extension based on an OID. Until now, I cannot find a solution without dynamically calling OBJ_create(OID, NULL. NULL).


Yun



From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Peter Waltenberg
Sent: 24 January 2018 01:23
To: Salz, Rich <rsalz at akamai.com>; openssl-dev at openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

It's also not that much of a problem in practice..
If you are using those API's you are adding new crypto. methods. Doing that after threading has started is not going to give good results with or without locking.

Peter




From:        "Salz, Rich via openssl-dev" <openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>>
To:        "openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>" <openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>>
Date:        24/01/2018 11:19
Subject:        Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c
Sent by:        "openssl-dev" <openssl-dev-bounces at openssl.org<mailto:openssl-dev-bounces at openssl.org>>
________________________________


  *   OpenSSL APIs, which makes the following OpenSSL documentation statement invalid (https://www.openssl.org/docs/man1.0.2/crypto/threads.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.0.2_crypto_threads.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o&s=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY&e=>)


  *   "OpenSSL can safely be used in multi-threaded applications provided that at least two callback functions are set, locking_function and threadid_func."


  *   Is there any planning to fix this issue?


Well, the most likely fix is to make the ?safely? wording be more vague, which I doubt you?ll like.  But I doubt anyone on the team has much interest in fixing 1.0.2 locking issues.--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs&s=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw&e=


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/c7c584b2/attachment-0001.html>

From bkaduk at akamai.com  Wed Jan 24 14:11:08 2018
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Wed, 24 Jan 2018 08:11:08 -0600
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
 crypto/objects/obj_dat.c
In-Reply-To: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
References: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
Message-ID: <761688cc-3ced-ffa7-14b6-af7cfe7e897b@akamai.com>

On 01/23/2018 07:19 PM, Salz, Rich via openssl-dev wrote:
>
>   * OpenSSL APIs, which makes the following OpenSSL documentation
>     statement invalid
>     (https://www.openssl.org/docs/man1.0.2/crypto/threads.html
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.0.2_crypto_threads.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o&s=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY&e=>)
>
> ?
>
>   * "OpenSSL can safely be used in multi-threaded applications
>     provided that at least two callback functions are set,
>     locking_function and threadid_func."
>
> ?
>
>   * Is there any planning to fix this issue?
>
> ?
>
> ?
>
> Well, the most likely fix is to make the ?safely? wording be more
> vague, which I doubt you?ll like.? But I doubt anyone on the team has
> much interest in fixing 1.0.2 locking issues.
>
>

Who said they were 1.0.2-specific?? Master's obj_dat.c still has a
completely unlocked OBJ_new_nid() that is a public API function; AFAICT
the issue is still present.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/c3693c19/attachment.html>

From mcr at sandelman.ca  Wed Jan 24 14:27:32 2018
From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 24 Jan 2018 09:27:32 -0500
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
Message-ID: <14302.1516804052@dooku.sandelman.ca>


Hubert Kario <hkario at redhat.com> wrote:
    > that marking a conversation as ignored and going to next one is two key
    > combinations and less than a second, github ones require me to go to
    > the web UI which is slow, and if I have to view the issue because
    > subject is ambiguous it takes ten times as long as it does when using
    > email

+1

    > email clients are designed to handle hundreds to thousands of messages
    > a day, Github UI isn't

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/df89bb13/attachment.sig>

From rsalz at akamai.com  Wed Jan 24 14:40:13 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Jan 2018 14:40:13 +0000
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
 crypto/objects/obj_dat.c
In-Reply-To: <8406c9abc40049ae95613dcc9965a3aa@realvnc.com>
References: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
 <OFD4395139.95F7DCC3-ON0025821F.0007719C-4A25821F.0007F2B0@notes.na.collabserv.com>
 <8406c9abc40049ae95613dcc9965a3aa@realvnc.com>
Message-ID: <946F27D3-6A7E-4701-B310-C09FD6D92D79@akamai.com>

Create the OID at your program startup and store the NID in a global variable.

From: Yun Jiang <yun.jiang at realvnc.com>
Reply-To: openssl-dev <openssl-dev at openssl.org>
Date: Wednesday, January 24, 2018 at 7:38 AM
To: openssl-dev <openssl-dev at openssl.org>
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

Thanks!

The problem is that I need to get a customized certificate extension based on an OID. Until now, I cannot find a solution without dynamically calling OBJ_create(OID, NULL. NULL).


Yun



From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Peter Waltenberg
Sent: 24 January 2018 01:23
To: Salz, Rich <rsalz at akamai.com>; openssl-dev at openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

It's also not that much of a problem in practice..
If you are using those API's you are adding new crypto. methods. Doing that after threading has started is not going to give good results with or without locking.

Peter




From:        "Salz, Rich via openssl-dev" <openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>>
To:        "openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>" <openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>>
Date:        24/01/2018 11:19
Subject:        Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c
Sent by:        "openssl-dev" <openssl-dev-bounces at openssl.org<mailto:openssl-dev-bounces at openssl.org>>
________________________________


  *   OpenSSL APIs, which makes the following OpenSSL documentation statement invalid (https://www.openssl.org/docs/man1.0.2/crypto/threads.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.0.2_crypto_threads.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o&s=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY&e=>)


  *   "OpenSSL can safely be used in multi-threaded applications provided that at least two callback functions are set, locking_function and threadid_func."


  *   Is there any planning to fix this issue?


Well, the most likely fix is to make the ?safely? wording be more vague, which I doubt you?ll like.  But I doubt anyone on the team has much interest in fixing 1.0.2 locking issues.--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs&s=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw&e=



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/2c1754c5/attachment-0001.html>

From yun.jiang at realvnc.com  Wed Jan 24 14:43:45 2018
From: yun.jiang at realvnc.com (Yun Jiang)
Date: Wed, 24 Jan 2018 14:43:45 +0000
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
 crypto/objects/obj_dat.c
In-Reply-To: <946F27D3-6A7E-4701-B310-C09FD6D92D79@akamai.com>
References: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
 <OFD4395139.95F7DCC3-ON0025821F.0007719C-4A25821F.0007F2B0@notes.na.collabserv.com>
 <8406c9abc40049ae95613dcc9965a3aa@realvnc.com>
 <946F27D3-6A7E-4701-B310-C09FD6D92D79@akamai.com>
Message-ID: <d6490a69a5384ed194d44ac422a75c6d@realvnc.com>

Thanks!

But we are providing SDK to our customers to retrieve extension from the certificates downloaded from Internet. We have no idea what OID will be used by the SDK users. Only SDK users will know what OID will be expected in a certificate.

OpenSSL should provide API to retrieve extension by OID.

Yun

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-dev
Sent: 24 January 2018 14:40
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

Create the OID at your program startup and store the NID in a global variable.

From: Yun Jiang <yun.jiang at realvnc.com<mailto:yun.jiang at realvnc.com>>
Reply-To: openssl-dev <openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>>
Date: Wednesday, January 24, 2018 at 7:38 AM
To: openssl-dev <openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>>
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

Thanks!

The problem is that I need to get a customized certificate extension based on an OID. Until now, I cannot find a solution without dynamically calling OBJ_create(OID, NULL. NULL).


Yun



From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Peter Waltenberg
Sent: 24 January 2018 01:23
To: Salz, Rich <rsalz at akamai.com<mailto:rsalz at akamai.com>>; openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>
Subject: Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

It's also not that much of a problem in practice..
If you are using those API's you are adding new crypto. methods. Doing that after threading has started is not going to give good results with or without locking.

Peter




From:        "Salz, Rich via openssl-dev" <openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>>
To:        "openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>" <openssl-dev at openssl.org<mailto:openssl-dev at openssl.org>>
Date:        24/01/2018 11:19
Subject:        Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c
Sent by:        "openssl-dev" <openssl-dev-bounces at openssl.org<mailto:openssl-dev-bounces at openssl.org>>
________________________________


  *   OpenSSL APIs, which makes the following OpenSSL documentation statement invalid (https://www.openssl.org/docs/man1.0.2/crypto/threads.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_man1.0.2_crypto_threads.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o&s=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY&e=>)


  *   "OpenSSL can safely be used in multi-threaded applications provided that at least two callback functions are set, locking_function and threadid_func."


  *   Is there any planning to fix this issue?


Well, the most likely fix is to make the ?safely? wording be more vague, which I doubt you?ll like.  But I doubt anyone on the team has much interest in fixing 1.0.2 locking issues.--
openssl-dev mailing list
To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY&m=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs&s=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw&e=


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/e76c4954/attachment-0001.html>

From rsalz at akamai.com  Wed Jan 24 14:51:31 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Jan 2018 14:51:31 +0000
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
 crypto/objects/obj_dat.c
In-Reply-To: <d6490a69a5384ed194d44ac422a75c6d@realvnc.com>
References: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
 <OFD4395139.95F7DCC3-ON0025821F.0007719C-4A25821F.0007F2B0@notes.na.collabserv.com>
 <8406c9abc40049ae95613dcc9965a3aa@realvnc.com>
 <946F27D3-6A7E-4701-B310-C09FD6D92D79@akamai.com>
 <d6490a69a5384ed194d44ac422a75c6d@realvnc.com>
Message-ID: <EADA20DC-4E23-4043-B981-D7995262364E@akamai.com>

  *   OpenSSL should provide API to retrieve extension by OID.

Yes!  Can you open a github issue for that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/e28f843a/attachment.html>

From openssl-users at dukhovni.org  Wed Jan 24 17:32:20 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 24 Jan 2018 12:32:20 -0500
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <14302.1516804052@dooku.sandelman.ca>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
 <14302.1516804052@dooku.sandelman.ca>
Message-ID: <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>



> On Jan 24, 2018, at 9:27 AM, Michael Richardson <mcr at sandelman.ca> wrote:
> 
>> email clients are designed to handle hundreds to thousands of messages
>> a day, Github UI isn't

Indeed email is best for informal ad-hoc back and forth threaded
discussion, while Github et. al. are for issue tracking.

If there's a clear problem that requires tracking and resolution,
then the right forum is Github.  If there's a topic to discuss,
we have openssl-users.  Most openssl-dev threads were more
appropriate for openssl-users.

So I'm not convinced we need two free-form discussion lists, but
concur that if it is discussion one wants, then email clearly
superior to Github issue tracking.  The key question is whether
openssl-users suffices to meet that need.

-- 
	Viktor.


From Matthias.St.Pierre at ncp-e.com  Wed Jan 24 17:55:32 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Wed, 24 Jan 2018 18:55:32 +0100
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
 <14302.1516804052@dooku.sandelman.ca>
 <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>
Message-ID: <af9dcc18-91ff-43ba-24df-de542bf36ca0@ncp-e.com>



On 24.01.2018 18:32, Viktor Dukhovni wrote:
>
>> On Jan 24, 2018, at 9:27 AM, Michael Richardson <mcr at sandelman.ca> wrote:
>>
>>> email clients are designed to handle hundreds to thousands of messages
>>> a day, Github UI isn't
> Indeed email is best for informal ad-hoc back and forth threaded
> discussion, while Github et. al. are for issue tracking.
>
> If there's a clear problem that requires tracking and resolution,
> then the right forum is Github.  If there's a topic to discuss,
> we have openssl-users.  Most openssl-dev threads were more
> appropriate for openssl-users.
>
> So I'm not convinced we need two free-form discussion lists, but
> concur that if it is discussion one wants, then email clearly
> superior to Github issue tracking.  The key question is whether
> openssl-users suffices to meet that need.
>

Although GitHub issues provide nice features like markdown and
syntax highlighting, I agree with Viktor that in general mailing lists are
much more suitable for general discussion. If nothing else, then because
they are open for everyone to read and search (via the mail archives)
and don't require a login.

So IMHO GitHub issues should remain for topics like bug reports and
specific discussions related to current pull requests.

As for the two mailing lists openssl-users and openssl-dev: It was always
my understanding that the former was for usability questions starting
from newbie questions up to very sophisticated subjects, whereas
openssl-dev was for discussion around the development process itself.
If we agree that mailing lists are preferrable to GitHub threads, then we
should not close down openssl-dev. Because openssl-project is readonly
for most developers and I don't think it would be a good idea
to join openssl-dev and openssl-users.

Matthias


From steffen at sdaoden.eu  Wed Jan 24 17:47:12 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 24 Jan 2018 18:47:12 +0100
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
 <14302.1516804052@dooku.sandelman.ca>
 <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>
Message-ID: <20180124174712.iuiDD%steffen@sdaoden.eu>

Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
 |> On Jan 24, 2018, at 9:27 AM, Michael Richardson <mcr at sandelman.ca> wrote:
 |>> email clients are designed to handle hundreds to thousands of messages
 |>> a day, Github UI isn't
 |
 |Indeed email is best for informal ad-hoc back and forth threaded
 |discussion, while Github et. al. are for issue tracking.
 |
 |If there's a clear problem that requires tracking and resolution,
 |then the right forum is Github.  If there's a topic to discuss,
 |we have openssl-users.  Most openssl-dev threads were more
 |appropriate for openssl-users.

I see an overwhelming amount of posts on the new list which where
somehow missed on -dev, though.

As a general note that you might not know, from Germany at least
and over my internet account and being not a logged in user i find
that github very often fails to generate commit data or cuts
directory listings.  At least there are no advertisings which
consume multiple CPUs for who-knows-what.

 |So I'm not convinced we need two free-form discussion lists, but
 |concur that if it is discussion one wants, then email clearly
 |superior to Github issue tracking.  The key question is whether
 |openssl-users suffices to meet that need.

Oh, -dev was a terribly noisy list.  So: ch-ch-ch-ch-changes
(turn and face the strange).

Congratulations for the price you have won.  Especially so in
respect to, brave new world!, having to go over browser based
issue tracker interfaces.  I could not do that.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From openssl-users at dukhovni.org  Wed Jan 24 18:08:54 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 24 Jan 2018 13:08:54 -0500
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <af9dcc18-91ff-43ba-24df-de542bf36ca0@ncp-e.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
 <14302.1516804052@dooku.sandelman.ca>
 <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>
 <af9dcc18-91ff-43ba-24df-de542bf36ca0@ncp-e.com>
Message-ID: <E7B6D7B5-4EA0-42D6-94C0-794FC58811F5@dukhovni.org>



> On Jan 24, 2018, at 12:55 PM, Dr. Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com> wrote:
> 
> As for the two mailing lists openssl-users and openssl-dev: It was always
> my understanding that the former was for usability questions starting
> from newbie questions up to very sophisticated subjects, whereas
> openssl-dev was for discussion around the development process itself.

Where "development process" means development of OpenSSL itself, not
software dependent on OpenSSL.  Since openssl is primarily a developer
toolkit, not end-user software, the openssl-users list is really for
developers, just not developers of OpenSSL itself.

> If we agree that mailing lists are preferrable to GitHub threads, then we
> should not close down openssl-dev.

Well, but we now have "openssl-project" for discussions of the
ongoing development of OpenSSL.  It is mostly for team members,
but though it is moderated, IIRC others can join and post.

> Because openssl-project is readonly for most developers

s/developers/users/

> and I don't think it would be a good idea to join openssl-dev
> and openssl-users.

Well, I've been on both for a long time, and mostly find that
I wish the openssl-dev posts were on openssl-users instead,
they really mostly aren't about ongoing OpenSSL development.

-- 
	Viktor.

From Matthias.St.Pierre at ncp-e.com  Wed Jan 24 18:25:06 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Wed, 24 Jan 2018 19:25:06 +0100
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <E7B6D7B5-4EA0-42D6-94C0-794FC58811F5@dukhovni.org>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
 <14302.1516804052@dooku.sandelman.ca>
 <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>
 <af9dcc18-91ff-43ba-24df-de542bf36ca0@ncp-e.com>
 <E7B6D7B5-4EA0-42D6-94C0-794FC58811F5@dukhovni.org>
Message-ID: <ac1d9361-c003-e131-5e83-f29cd3eaab58@ncp-e.com>


On 24.01.2018 19:08, Viktor Dukhovni wrote:
>
> Well, but we now have "openssl-project" for discussions of the
> ongoing development of OpenSSL.  It is mostly for team members,
> but though it is moderated, IIRC others can join and post.
Ok, I didn't know that. If anyone seriously participating on GitHub can
join the moderated openssl-project list then this sounds like a good
replacement for openssl-dev, because that list will be more focused
and not bothered with so many misplaced posts that should have
gone to openssl-users.

Matthias


From openssl-users at dukhovni.org  Wed Jan 24 18:27:39 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 24 Jan 2018 13:27:39 -0500
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <ac1d9361-c003-e131-5e83-f29cd3eaab58@ncp-e.com>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
 <14302.1516804052@dooku.sandelman.ca>
 <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>
 <af9dcc18-91ff-43ba-24df-de542bf36ca0@ncp-e.com>
 <E7B6D7B5-4EA0-42D6-94C0-794FC58811F5@dukhovni.org>
 <ac1d9361-c003-e131-5e83-f29cd3eaab58@ncp-e.com>
Message-ID: <57EE1D70-F927-479E-AB16-DE62FADEB25C@dukhovni.org>



> On Jan 24, 2018, at 1:25 PM, Dr. Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com> wrote:
> 
> Ok, I didn't know that. If anyone seriously participating on GitHub can
> join the moderated openssl-project list then this sounds like a good
> replacement for openssl-dev, because that list will be more focused
> and not bothered with so many misplaced posts that should have
> gone to openssl-users.

Interested participants can sign up at:

  https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
	Viktor.


From mcr at sandelman.ca  Wed Jan 24 18:58:18 2018
From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 24 Jan 2018 13:58:18 -0500
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>
References: <BC9EA3C9-8748-4075-81E3-3256D9696880@akamai.com>
 <2187057.qOMJW3ZjMn@pintsize.usersys.redhat.com>
 <DAC7A2F6-0673-4836-8897-C04B7A56A9BF@akamai.com>
 <1825521.mmB0qapBzR@pintsize.usersys.redhat.com>
 <14302.1516804052@dooku.sandelman.ca>
 <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>
Message-ID: <22025.1516820298@obiwan.sandelman.ca>


Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
    >> On Jan 24, 2018, at 9:27 AM, Michael Richardson <mcr at sandelman.ca> wrote:
    >>
    >>> email clients are designed to handle hundreds to thousands of messages
    >>> a day, Github UI isn't

    > Indeed email is best for informal ad-hoc back and forth threaded
    > discussion, while Github et. al. are for issue tracking.

    > If there's a clear problem that requires tracking and resolution,
    > then the right forum is Github.  If there's a topic to discuss,
    > we have openssl-users.  Most openssl-dev threads were more
    > appropriate for openssl-users.

I'm okay with taking more of the "what is the right answer" questions to
openssl-users if that's the plan.

I truly love github for many many things, but the email interface to issues
and pull requests has been a problem for me with projects like tcpdump.
I personally don't render HTML parts, and read 90% of my email via
emacsclient -nw.

Users reasonably post things. 60% are silly requests which a google search or
a "man foo" would resolve.... but it generates emails to the busiest people
only (the maintainers), skipping the other users on the list who *also* could
answer if they knew there was a well formed question.

Is there a stackexchange/serverfault?

I took to CC: tcpdump-workers when I answered github issues by email,
particularly when there was a question of project goals or policy involved.
I realized that there is a bit of a XSS/spam attack facilitated by doing that
as the magic reply-to address to get stuff posted to the github issue is now
happily archived in the ML!

Does github issue process the emails with useful quoting in them usefully? Sorta.
So, I'm skeptical, but I am willing to go with the plan.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/1e5c17f8/attachment.sig>

From rsalz at akamai.com  Wed Jan 24 22:32:31 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Jan 2018 22:32:31 +0000
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
 crypto/objects/obj_dat.c
In-Reply-To: <da67f587405a4c71ac389676e6067507@realvnc.com>
References: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
 <da67f587405a4c71ac389676e6067507@realvnc.com>
Message-ID: <72440643-C30B-4F7E-8A4E-31CCB8A0E97E@akamai.com>

  *   Well, the most likely fix is to make the ?safely? wording be more vague, which I doubt you?ll like.  But I doubt anyone on the team has much interest in fixing 1.0.2 locking issues.



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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/ce902a55/attachment-0001.html>

From wiml at omnigroup.com  Wed Jan 24 23:45:57 2018
From: wiml at omnigroup.com (Wim Lewis)
Date: Wed, 24 Jan 2018 15:45:57 -0800
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
	crypto/objects/obj_dat.c
In-Reply-To: <761688cc-3ced-ffa7-14b6-af7cfe7e897b@akamai.com>
References: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
 <761688cc-3ced-ffa7-14b6-af7cfe7e897b@akamai.com>
Message-ID: <3EA3742A-9EB8-4C65-B192-8ACC00A7D896@omnigroup.com>

On 24. jan. 2018, at 6:11 f.h., Benjamin Kaduk via openssl-dev <openssl-dev at openssl.org> wrote:
> On 01/23/2018 07:19 PM, Salz, Rich via openssl-dev wrote:
>> Well, the most likely fix is to make the ?safely? wording be more vague, which I doubt you?ll like.  But I doubt anyone on the team has much interest in fixing 1.0.2 locking issues.
> 
> Who said they were 1.0.2-specific?  Master's obj_dat.c still has a completely unlocked OBJ_new_nid() that is a public API function; AFAICT the issue is still present.

As you say, this really doesn't seem to be a 1.0.x-specific problem. The current development tip on github has the same issue (and the same language in doc/man3/CRYPTO_THREAD_run_once.pod).

The current patch ( PR 5164 ) just changes "can be safely used" to "can generally be used safely". Without enough information for a user of the library to know whether a given usage is safe, this isn't useful documentation. When it comes to threading, "generally safe" is the same as "unsafe". There needs to be at least a little bit of guidance.

A quick check of my system's openssl 1.1 libraries shows 280 mutable global variables in libcrypto and 36 in libssl. Most of those are presumably protected by locks or are only set during init; for the remaining actual thread-unsafe variables, it should be possible to document the small number of APIs which affect them.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/e4d649d8/attachment.html>

From rsalz at akamai.com  Wed Jan 24 23:51:38 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Jan 2018 23:51:38 +0000
Subject: [openssl-dev] About multi-thread unsafe for APIs defined in
 crypto/objects/obj_dat.c
In-Reply-To: <3EA3742A-9EB8-4C65-B192-8ACC00A7D896@omnigroup.com>
References: <A6979141-DA42-46E6-B8DC-1A22161B4AB2@akamai.com>
 <761688cc-3ced-ffa7-14b6-af7cfe7e897b@akamai.com>
 <3EA3742A-9EB8-4C65-B192-8ACC00A7D896@omnigroup.com>
Message-ID: <847D84AC-3A0F-4389-80DD-10C4FCF70BD3@akamai.com>

  *   The current patch ( PR 5164 ) just changes "can be safely used" to "can generally be used safely". Without enough information for a user of the library to know whether a given usage is safe, this isn't useful documentation. When it comes to threading, "generally safe" is the same as "unsafe". There needs to be at least a little bit of guidance.

Pedantically and strictly speaking, you might be correct.  Pragmatically, however, many people have been able to write or deploy multi-threaded servers.

I doubt that anyone on the project will do anything approaching a definitive thread-safety analysis, let alone documentation.  Even with the ?small number of API?s? that might be affected.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20180124/96bfb7dd/attachment.html>

From levitte at openssl.org  Thu Jan 25 10:11:09 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 25 Jan 2018 11:11:09 +0100 (CET)
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <E7B6D7B5-4EA0-42D6-94C0-794FC58811F5@dukhovni.org>
References: <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>
 <af9dcc18-91ff-43ba-24df-de542bf36ca0@ncp-e.com>
 <E7B6D7B5-4EA0-42D6-94C0-794FC58811F5@dukhovni.org>
Message-ID: <20180125.111109.916271037232940782.levitte@openssl.org>

In message <E7B6D7B5-4EA0-42D6-94C0-794FC58811F5 at dukhovni.org> on Wed, 24 Jan 2018 13:08:54 -0500, Viktor Dukhovni <openssl-users at dukhovni.org> said:

openssl-users> > If we agree that mailing lists are preferrable to
openssl-users> > GitHub threads, then we should not close down
openssl-users> > openssl-dev.
openssl-users> 
openssl-users> Well, but we now have "openssl-project" for discussions
openssl-users> of the ongoing development of OpenSSL.  It is mostly
openssl-users> for team members, but though it is moderated, IIRC
openssl-users> others can join and post.

This is confusing, and not what was intended.  In other words,
openssl-project is *not* a new openssl-dev!  If it was, I don't see
why we would even bother making a new list...

>From the blog entry:

> We created a new mailing list, openssl-project, that is for
> discussions about the governance and policies of OpenSSL. Anyone can
> join this list. Only members of the OMC and committers will be able
> to post.

Governance and policies (roughly speaking, 'cause there may be some
derailing that's shouldn't be there) is not, as far as I understand,
"development of OpenSSL".  It may be close, thought, such as planning
the schedule of the next release.

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

From openssl-users at dukhovni.org  Thu Jan 25 17:30:57 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 25 Jan 2018 12:30:57 -0500
Subject: [openssl-dev] Blog post; changing in email, crypto policy, etc
In-Reply-To: <20180125.111109.916271037232940782.levitte@openssl.org>
References: <E9AFFA0E-1C6A-4B8C-A53B-19953EB660D1@dukhovni.org>
 <af9dcc18-91ff-43ba-24df-de542bf36ca0@ncp-e.com>
 <E7B6D7B5-4EA0-42D6-94C0-794FC58811F5@dukhovni.org>
 <20180125.111109.916271037232940782.levitte@openssl.org>
Message-ID: <33814AD3-16AB-4257-89F0-900186F2E05B@dukhovni.org>



> On Jan 25, 2018, at 5:11 AM, Richard Levitte <levitte at openssl.org> wrote:
> 
> This is confusing, and not what was intended.  In other words,
> openssl-project is *not* a new openssl-dev!  If it was, I don't see
> why we would even bother making a new list...

It is moderated, and won't have misplaced user questions.  Technical
topics related to the future evolution of OpenSSL should I think be
open for discussion on this list if they're not yet sufficiently
well formulated for tracking as a GitHub issue.  These might be design
ideas, clarification of requirements, ...  The point being that mailing
lists are good for *discussion* and Github is not particularly well
suited for that.

-- 
	Viktor.