subject:"RE\:"

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


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

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

2018-01-24 Thread Wim Lewis

On 24. jan. 2018, at 6:11 f.h., Benjamin Kaduk via openssl-dev 
 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.

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

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

  *   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


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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-24 Thread Michael Richardson

Viktor Dukhovni  wrote:
>> On Jan 24, 2018, at 9:27 AM, Michael Richardson  
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  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-24 Thread Viktor Dukhovni



> On Jan 24, 2018, at 1:25 PM, Dr. Matthias St. Pierre 
>  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.

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-24 Thread Dr. Matthias St. Pierre


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

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-24 Thread Viktor Dukhovni

> On Jan 24, 2018, at 12:55 PM, Dr. Matthias St. Pierre 
>  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.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-24 Thread Steffen Nurpmeso

Viktor Dukhovni  wrote:
 |> On Jan 24, 2018, at 9:27 AM, Michael Richardson  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)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-24 Thread Dr. Matthias St. Pierre

On 24.01.2018 18:32, Viktor Dukhovni wrote:
>
>> On Jan 24, 2018, at 9:27 AM, Michael Richardson  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

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-24 Thread Viktor Dukhovni

> On Jan 24, 2018, at 9:27 AM, Michael Richardson  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.

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

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

  *   OpenSSL should provide API to retrieve extension by OID.

Yes!  Can you open a github issue for that?
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

2018-01-24 Thread Yun Jiang

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-boun...@openssl.org] On Behalf Of Salz, 
Rich via openssl-dev
Sent: 24 January 2018 14:40
To: openssl-dev@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.ji...@realvnc.com<mailto:yun.ji...@realvnc.com>>
Reply-To: openssl-dev <openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>>
Date: Wednesday, January 24, 2018 at 7:38 AM
To: openssl-dev <openssl-dev@openssl.org<mailto:openssl-dev@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-boun...@openssl.org] On Behalf Of Peter 
Waltenberg
Sent: 24 January 2018 01:23
To: Salz, Rich <rs...@akamai.com<mailto:rs...@akamai.com>>; 
openssl-dev@openssl.org<mailto:openssl-dev@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@openssl.org<mailto:openssl-dev@openssl.org>>
To:"openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>" 
<openssl-dev@openssl.org<mailto:openssl-dev@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-boun...@openssl.org<mailto:openssl-dev-boun...@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=DwMFAw=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY=>)


  *   "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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw=


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

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.ji...@realvnc.com>
Reply-To: openssl-dev <openssl-dev@openssl.org>
Date: Wednesday, January 24, 2018 at 7:38 AM
To: openssl-dev <openssl-dev@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-boun...@openssl.org] On Behalf Of Peter 
Waltenberg
Sent: 24 January 2018 01:23
To: Salz, Rich <rs...@akamai.com>; openssl-dev@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@openssl.org<mailto:openssl-dev@openssl.org>>
To:"openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>" 
<openssl-dev@openssl.org<mailto:openssl-dev@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-boun...@openssl.org<mailto:openssl-dev-boun...@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=DwMFAw=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY=>)

  *   "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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw=

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-24 Thread Michael Richardson


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



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

2018-01-24 Thread Benjamin Kaduk via openssl-dev

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
> 
> )
>
>  
>
>   * "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
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

2018-01-24 Thread Yun Jiang

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-boun...@openssl.org] On Behalf Of Peter 
Waltenberg
Sent: 24 January 2018 01:23
To: Salz, Rich <rs...@akamai.com>; openssl-dev@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@openssl.org<mailto:openssl-dev@openssl.org>>
To:"openssl-dev@openssl.org<mailto:openssl-dev@openssl.org>" 
<openssl-dev@openssl.org<mailto:openssl-dev@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-boun...@openssl.org<mailto:openssl-dev-boun...@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=DwMFAw=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY=>)


  *   "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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=xEO93f-eFk98ZtSS2VW5oQoqCSoxBFAun8n0dZayTrs=9NZPKi5lqIGH6Jq4RqlHOiKqzuqUqZQMEQvpBr3aKsw=


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

Re: [openssl-dev] About multi-thread unsafe for APIs defined in crypto/objects/obj_dat.c

2018-01-24 Thread Yun Jiang

Thanks! Is this issue fixed in 1.1.0?

Yun

From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Salz, 
Rich via openssl-dev
Sent: 24 January 2018 01:19
To: openssl-dev@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=DwMFAw=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=ZS_kRxGa4vj0O6wqfY-6q7kwVT0WiIMkFqw1XWHym4o=GK3QtuXP-8j_1nbRihxeJGLAIYXt1BNIyh3WHP6EJlY=>)


Ø  "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://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-23 Thread Florian Weimer

* 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.)
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-23 Thread Richard Levitte

In message <8c351e82-600b-487e-aef3-a3f42cd23...@akamai.com> on Tue, 23 Jan 
2018 14:38:14 +, "Salz, Rich via openssl-dev"  
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 levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

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

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

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




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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-23 Thread Dr. Matthias St. Pierre

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.

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc


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

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

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

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-23 Thread Jan Ehrhardt

Salz, Rich via open ssl-dev in gmane.comp.encryption.openssl.devel
(Fri, 19 Jan 2018 17:34:57 +):
>- 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

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

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

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-23 Thread Dmitry Belyavsky

Hello,

On Tue, Jan 23, 2018 at 3:00 PM, Hubert Kario  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
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-19 Thread Blumenthal, Uri - 0553 - MITLL

On 1/19/18, 12:52, "Salz, Rich"  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.



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-19 Thread Salz, Rich via openssl-dev

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

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

Re: [openssl-dev] Blog post; changing in email, crypto policy, etc

2018-01-19 Thread Blumenthal, Uri - 0553 - MITLL

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



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

2018-01-19 Thread Matt Caswell



On 19/01/18 16:32, Michael Richardson wrote:
> Matt Caswell  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
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

2018-01-19 Thread Michael Richardson

Matt Caswell  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  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

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

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

2018-01-19 Thread Matt Caswell

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

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

Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface

2018-01-18 Thread Kurt Roeckx

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

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

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

2018-01-18 Thread Michael Richardson


Matt Caswell  wrote:
>> Matt Caswell  wrote:
>> >> Matt Caswell  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  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface

2018-01-18 Thread Patrick Steuer


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 ?
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface

2018-01-17 Thread Peter Waltenberg

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 
To: openssl-dev 
Date:   18/01/2018 04:10
Subject:[openssl-dev] evp cipher/digest - add alternative to 
init-update-final interface
Sent by:"openssl-dev" 



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=DwICAg=jf_iaSHvJObTbx-siA1ZOg=K53ZTnW2gq2IjM1tbpz7kYoHgvTfJ_aR8s4bK_o2xzY=dCZ2v-6pJfzfrbfJZcLHkWMH1rQl8LHFyYrTC8IWaDQ=upMfA8eZGxh6kmIwqjO38Chm2MNi_BocHjrm84jCvOU=

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

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






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

Re: [openssl-dev] evp cipher/digest - add alternative to init-update-final interface

2018-01-17 Thread Benjamin Kaduk via openssl-dev

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
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

2018-01-17 Thread Michael Richardson


Matt Caswell  wrote:
>> Matt Caswell  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).

> Ahhhits 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  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [EXTERNAL] Re: PKCS12 safecontents bag type deviation from spec

2018-01-17 Thread Tomas Mraz

On Tue, 2018-01-16 at 19:31 +, Sands, Daniel wrote:
> On Tue, 2018-01-16 at 14:50 +, 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.]

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

Re: [openssl-dev] [EXTERNAL] Re: PKCS12 safecontents bag type deviation from spec

2018-01-16 Thread Blumenthal, Uri - 0553 - MITLL

I think the change is justified.
—
Regards,
Uri

> On Jan 16, 2018, at 14:31, Sands, Daniel  wrote:
> 
> On Tue, 2018-01-16 at 14:50 +, 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

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

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

2018-01-16 Thread Matt Caswell



On 16/01/18 19:44, Michael Richardson wrote:
> 
> Matt Caswell  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).

Ahhhits 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

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

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

2018-01-16 Thread Michael Richardson

Matt Caswell <m...@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, _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  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [EXTERNAL] Re: PKCS12 safecontents bag type deviation from spec

2018-01-16 Thread Sands, Daniel

On Tue, 2018-01-16 at 14:50 +, 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

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

2018-01-16 Thread Matt Caswell



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, _addr, sizeof(struct sockaddr_in6));
 connect(client_fd, _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, _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
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl/openssl] Dtls listen refactor (#5024)

2018-01-16 Thread Michael Richardson

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

Re: [openssl-dev] PKCS12 safecontents bag type deviation from spec

2018-01-16 Thread Salz, Rich via openssl-dev

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)



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

Re: [openssl-dev] NonStop platform support

2018-01-11 Thread Randall S. Becker

On January 9, 2018 10:10 AM, Richard Levitte wrote:
> On Jan 2018 09:32:25 -0500, "Randall S. Becker" 
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

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-09 Thread Daniel Kahn Gillmor

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

signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-09 Thread Wim Lewis

On 9. jan. 2018, at 7:40 f.h., Randall S. Becker  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

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-09 Thread William Bathurst


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

>

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




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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-09 Thread William Bathurst


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)


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


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

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

2018-01-09 Thread Misaki Miyashita




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@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
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

2018-01-09 Thread Benjamin Kaduk via openssl-dev

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

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

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

2018-01-09 Thread Misaki Miyashita




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@openssl.org 
alias? or filing an issue via github is the right course of action?


Thanks again for your comment.

Regards,

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-09 Thread Hubert Kario

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

signature.asc
Description: This is a digitally signed message part.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] NonStop platform support

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" 
> 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 developer since approximately
UNIX(421664400)/NonStop(2112884442)
-- In my real life, I talk too much.



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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

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.

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-09 Thread Salz, Rich via openssl-dev

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.

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

On January 9, 2018 9:46 AM Benjamin Kaduk wrote:
> To: openssl-dev@openssl.org; Randall S. Becker 
> 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

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-09 Thread Benjamin Kaduk via openssl-dev

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
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

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

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

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

2018-01-09 Thread Benjamin Kaduk via openssl-dev

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@openssl.org)
>>
>> I would like to suggest the following fix so that a valid certificate
>> at .x can be recognized during the cert validation even when
>> .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
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-09 Thread Salz, Rich via openssl-dev


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

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-09 Thread Hanno Böck

Hi,

I'm not particularly convinced.

On Mon, 8 Jan 2018 13:10:07 -0800
William Bathurst  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: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-09 Thread Dmitry Belyavsky

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  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
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-09 Thread Blumenthal, Uri - 0553 - MITLL

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 <levi...@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@default> on Mon, 8 Jan 2018 
> 13:58:59 -0800 (PST), Paul Dale <paul.d...@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:wbath...@gmail.com] 
> paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM
> paul.dale> To: openssl-dev@openssl.org
> paul.dale> Cc: llamour...@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 followi

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

2018-01-08 Thread Misaki Miyashita




On 01/ 8/18 04:46 PM, Misaki Miyashita wrote:

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

I would like to suggest the following fix so that a valid certificate 
at .x can be recognized during the cert validation even when 
.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.c2017-11-02 07:32:58.0 -0700
+++ b/crypto/x509/x509_vfy.c2017-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;
+inti;
+intret = 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(, ctx, x);
-if ((ok <= 0) || X509_cmp(x, xtmp)) {
+if ((ok <= 0) || (X509_get_cert(, 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 
 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.





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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-08 Thread Richard Levitte

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@default> on Mon, 8 Jan 2018 
13:58:59 -0800 (PST), Paul Dale <paul.d...@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:wbath...@gmail.com] 
paul.dale> Sent: Tuesday, 9 January 2018 7:10 AM
paul.dale> To: openssl-dev@openssl.org
paul.dale> Cc: llamour...@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 B

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-08 Thread 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.

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:wbath...@gmail.com] 
Sent: Tuesday, 9 January 2018 7:10 AM
To: openssl-dev@openssl.org
Cc: llamour...@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 <wbath...@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
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-users] Failed to access LDAP server when a valid certificate is at .1+

2018-01-08 Thread Misaki Miyashita


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

I would like to suggest the following fix so that a valid certificate at 
.x can be recognized during the cert validation even when .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.c2017-11-02 07:32:58.0 -0700
+++ b/crypto/x509/x509_vfy.c2017-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;
+inti;
+intret = 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(, ctx, x);
-if ((ok <= 0) || X509_cmp(x, xtmp)) {
+if ((ok <= 0) || (X509_get_cert(, 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  
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.



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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-08 Thread Benjamin Kaduk via openssl-dev

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-08 Thread William Bathurst

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

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-05 Thread Daniel Kahn Gillmor

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

signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Speck Cipher Integration with OpenSSL

2018-01-05 Thread Hanno Böck

On Fri, 5 Jan 2018 10:52:01 -0800
William Bathurst  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: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] weird loop in s3_lib.c

2018-01-03 Thread Michael Richardson


Michael Richardson  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  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[



signature.asc
Description: PGP signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Is X509_free(NULL) ok?

2018-01-01 Thread Salz, Rich via openssl-dev

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


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

Re: [openssl-dev] Is X509_free(NULL) ok?

➢So it's guaranteed for 1.1, mostly guaranteed for recent 1.0.2, but not
guaranteed for older 1.0.2.

yes.


➢ I also think it would be good to backport all to 1.0.2

Yes.  I believe I did that, but I am not absolutely 100% positive.

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

Re: [openssl-dev] Is X509_free(NULL) ok?

2017-12-22 Thread Ken Goldman


On 12/22/2017 9:59 AM, Salz, Rich via openssl-dev wrote:


I think we fixed all such cases in 1.1.0, all *_free()
functions should handle NULL. I don't think we backported to changes
to 1.0.2.

Yes, and we fixed the documentation.  I backported all/most of them
to 1.0.2 to make cherry-picking easier.  I don’t know if I changed
the docs.


So it's guaranteed for 1.1, mostly guaranteed for recent 1.0.2, but not
guaranteed for older 1.0.2.

If that's the case, I suspect it's just as easy to leave the

if (ptr != NULL)

in the code, as to code an ifdef for version < 1.1.

~~

I also think it would be good to backport all to 1.0.2.  If the 
documentation says it's OK in 1.1, and the coder uses the 1.1 API,

the end user may get crashes if they compile against 1.0.2.




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

Re: [openssl-dev] Is X509_free(NULL) ok?


➢ I think we fixed all such cases in 1.1.0, all *_free() functions
should handle NULL. I don't think we backported to changes to 1.0.2.

Yes, and we fixed the documentation.  I backported all/most of them to 1.0.2 to 
make cherry-picking easier.  I don’t know if I changed the docs.

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

Re: [openssl-dev] Is X509_free(NULL) ok?

2017-12-22 Thread Kurt Roeckx

On Fri, Dec 22, 2017 at 09:30:19AM -0500, Ken Goldman wrote:
> On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote:
> > >   if (ptr!= NULL) free(ptr);
> > That shouldn’t be necessary for OpenSSL.  If you find places where it is, 
> > please open an issue.
> 
> OK.  I'll mention a few, but it's a global issue.
> 
> The code may handle NULL.  However, conservative users won't go by what the
> code happens to do today.  We have to go by the API documentation, which is
> the contract between the library and the user.  If the API is silent, we
> cautiously assume it's not guaranteed, and can change in the future.

So feel free to document it as being able to handle NULL.


Kurt

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

Re: [openssl-dev] Is X509_free(NULL) ok?

2017-12-22 Thread Kurt Roeckx

On Fri, Dec 22, 2017 at 01:06:20PM +, Salz, Rich via openssl-dev wrote:
> Our intent is that all FREE functions can handle NULL.  If you find things 
> missing or undocumented, please open an issue on GitHub.  Thanks!

I think we fixed all such cases in 1.1.0, all *_free() functions
should handle NULL. I don't think we backported to changes to 1.0.2.


Kurt

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

Re: [openssl-dev] Is X509_free(NULL) ok?

2017-12-22 Thread Ken Goldman


On 12/22/2017 9:24 AM, Salz, Rich via openssl-users wrote:

if (ptr!= NULL) free(ptr);
   
That shouldn’t be necessary for OpenSSL.  If you find places where it is, please open an issue.
   


OK.  I'll mention a few, but it's a global issue.

The code may handle NULL.  However, conservative users won't go by what 
the code happens to do today.  We have to go by the API documentation, 
which is the contract between the library and the user.  If the API is 
silent, we cautiously assume it's not guaranteed, and can change in the 
future.





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

Re: [openssl-dev] [openssl-users] Is X509_free(NULL) ok?

>   if (ptr!= NULL) free(ptr);
  
That shouldn’t be necessary for OpenSSL.  If you find places where it is, 
please open an issue.
  
➢ BTW, "can handle" should explicitly say what happens.  Perhaps use the C 
library text, which says:

If ptr is NULL, no operation is performed.
  
That is the wording we use.

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

Re: [openssl-dev] Is X509_free(NULL) ok?