Re: [openssl-project] Entropy seeding the DRBG
Like I think I mentioned a few days ago, I'm currently on a conference. I'll take this up in more depth later this week. I have a question, though... Kurt said at some point that all that was needed on the VMS side was to collect data, the rest can be done elsewhere (thankfully). However, I don't really understand what the collected data is supposed to be. Just the same stream of bytes that I would feed the entropy acquisition, or something else? Is the time delta between samples a factor in this? Cheers Richard Paul Dale skrev: (24 april 2018 00:31:39 CEST) >I can possibly provide some input having done similar for a number of >platforms and written faster but equivalent entropy assessment code to >NIST's (for the second draft of SP 800-90B rather than the final >version). > >I'm not knowledgeable about VMS though. > >We could discuss further at ICMC if you're in the area. > > >Pauli -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test
> On Apr 22, 2018, at 9:49 PM, Viktor Dukhovni > wrote: > > - Client-side diagnostics - On the server side I see that even when the ticket callback returns "0" to accept and not re-issue the ticket, a new ticket is requested anyway. I'd like to be able to control this, and not issue new tickets when the present ticket is acceptable. If this requires new API entry points, I can condition them on a suitable min library version. But ideally the callback return value will be honoured, I don't yet see why we would not do that. - Server-side diagnostics - Initial session: SSL_accept:before SSL initialization SSL_accept:before SSL initialization SSL_accept:SSLv3/TLS read client hello SSL_accept:SSLv3/TLS write server hello SSL_accept:SSLv3/TLS write change cipher spec SSL_accept:TLSv1.3 write encrypted extensions SSL_accept:SSLv3/TLS write certificate SSL_accept:TLSv1.3 write server certificate verify SSL_accept:SSLv3/TLS write finished SSL_accept:TLSv1.3 early data SSL_accept:TLSv1.3 early data SSL_accept:SSLv3/TLS read finished >>> Callback log entry, create initial ticket: Issuing session ticket, key expiration: 1524534619 SSL_accept:SSLv3/TLS write session ticket >>> Post-handshake SMTP server log entry: Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) Resumed session: SSL_accept:before SSL initialization SSL_accept:before SSL initialization >>> Callback log entry, decrypting presented ticket: Decrypting session ticket, key expiration: 1524534619 SSL_accept:SSLv3/TLS read client hello SSL_accept:SSLv3/TLS write server hello SSL_accept:SSLv3/TLS write change cipher spec SSL_accept:TLSv1.3 write encrypted extensions SSL_accept:SSLv3/TLS write finished SSL_accept:TLSv1.3 early data SSL_accept:TLSv1.3 early data SSL_accept:SSLv3/TLS read finished >>> Callback asked to create a new ticket: Issuing session ticket, key expiration: 1524534619 SSL_accept:SSLv3/TLS write session ticket >>> Post-handshake application logging: Reusing old session (RFC 5077 session ticket) Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) - End - -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test
> On Apr 23, 2018, at 3:35 AM, Matt Caswell wrote: > >> * With TLS 1.3 a new session is generated even sessions are >>resumed, because the server responds with a new ticket >>in the event of session resumption. With TLS 1.2 sessions >>that had sufficient remaining lifetime did not trigger new >>ticket generation on the server, and no new session was >>stored on the client. This causes needless wear-and-tear >>on the external session cache in Postfix, since each >>connection writes out a new session, replacing the one >>it just used. Some might consider this a security feature, >>but it is not especially desirable with SMTP. Any thoughts >>about whether this could be tunable? It would have to be >>server-side tuning I think, since the client does not know >>why the server issued a new session, perhaps the old one >>was not (or will soon not) be valid for re-use. > > Note that some servers may actually issue more than one ticket per > connection. Notably boring issues 2 by default. I'm not sure if they > enable configuration of that. To be clear, I'm looking for server-side controls, so that, for example, in the Postfix SMTP server when the presented ticket has sufficient lifetime left (as is the case with TLS 1.2), no new session tickets are generated. The Postfix SMTP server sets up a ticket callback: https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L303 and so can signal the SSL engine to accept or re-issue the ticket. Presently tickets are always accepted and periodically a new handshake takes place when the ticket is no longer valid. > In servers that accept early data we enforce single use tickets. In > those scenarios it may make sense to have more than one ticket issued > per connection. There's no early data in SMTP STARTTLS. > I do have a WIP PR for enabling configuration of the number of tickets > to be sent on the server side: > > https://github.com/openssl/openssl/pull/5227 > > I have not been prioritising that at the moment because I have been > focussing more on fixing defects. I'll take a look... -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] FW: [Curdle] I-D Action: draft-ietf-curdle-pkix-09.txt
On 21/04/18 13:22, Salz, Rich wrote: > Anyone up for a doing a PR that adds these to objects.txt? They're already in there: https://github.com/openssl/openssl/blob/master/crypto/objects/objects.txt#L1581 Matt > > On 4/20/18, 5:23 PM, "internet-dra...@ietf.org" > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the CURves, Deprecating and a Little more > Encryption WG of the IETF. > > Title : Algorithm Identifiers for Ed25519, Ed448, > X25519 and X448 for use in the Internet X.509 Public Key Infrastructure > Authors : Simon Josefsson > Jim Schaad > Filename: draft-ietf-curdle-pkix-09.txt > Pages : 18 > Date: 2018-04-20 > > Abstract: >This document specifies algorithm identifiers and ASN.1 encoding >formats for Elliptic Curve constructs using the curve25519 and >curve448 curves. The signature algorithms covered are Ed25519 and >Ed448. The key agreement algorithm covered are X25519 and X448. The >encoding for Public Key, Private Key and EdDSA digital signature >structures is provided. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-pkix-09 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-09 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > Curdle mailing list > cur...@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > > ___ > openssl-project mailing list > openssl-project@openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-project > ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Entropy seeding the DRBG
I can possibly provide some input having done similar for a number of platforms and written faster but equivalent entropy assessment code to NIST's (for the second draft of SP 800-90B rather than the final version). I'm not knowledgeable about VMS though. We could discuss further at ICMC if you're in the area. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -Original Message- From: Kurt Roeckx [mailto:k...@roeckx.be] Sent: Tuesday, 24 April 2018 5:46 AM To: openssl-project@openssl.org Subject: Re: [openssl-project] Entropy seeding the DRBG On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote: > In the mean time, I've spent a few days going through the docs on all > kinds of data that you can get out from the VMS kernel, most notably > through a system service called sys$getrmi()... there's a gazillion > data points, a treasure trove for anyone that's into statistics. And > I intend to spend some time trying to estimate what kind of entropy I > can get out of them... > > ... and that's where Kurt came in: > > > Can I suggest you try something like > > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least > > get an idea? You would need to sample 1 variable and feed that into > > it. > > And yeah, sure, especially if all it takes is to produce a stream of > bits from a source and feed that to the assessment program. As long > as I don't have to port a C++11 program to VMS, 'cause unfortunately, > the existing C++ compiler hasn't had a real update for quite a while > :-/ (I'm sure that VSI is quite busy updating all they can, but they > haven't let anything out yet) > > But either way, creating a better entropy gatherer is the longer term > goal. I hope I get that part done before the release. Any update on this? Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Entropy seeding the DRBG
On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote: > In the mean time, I've spent a few days going through the docs on all > kinds of data that you can get out from the VMS kernel, most notably > through a system service called sys$getrmi()... there's a gazillion > data points, a treasure trove for anyone that's into statistics. And > I intend to spend some time trying to estimate what kind of entropy I > can get out of them... > > ... and that's where Kurt came in: > > > Can I suggest you try something like > > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least > > get an idea? You would need to sample 1 variable and feed that into > > it. > > And yeah, sure, especially if all it takes is to produce a stream of > bits from a source and feed that to the assessment program. As long > as I don't have to port a C++11 program to VMS, 'cause unfortunately, > the existing C++ compiler hasn't had a real update for quite a while > :-/ (I'm sure that VSI is quite busy updating all they can, but they > haven't let anything out yet) > > But either way, creating a better entropy gatherer is the longer term > goal. I hope I get that part done before the release. Any update on this? Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test
In message on Sun, 22 Apr 2018 21:49:42 -0400, Viktor Dukhovni said: openssl-users> * Postfix logs a warning when the compile-time and runtime openssl-users> libraries are not exactly the same (once per process start), openssl-users> this is expected. Perhaps we should provide a means for openssl-users> users to turn that off. With our current version scheme, you should use the compatibility mask 0xFFF0 (maybe we should have that value in opensslv.h... Matthias St. Pierre might have an idea or two on the matter, too) Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test
I tested a Postfix server and client built against OpenSSL 1.1.0, using 1.1.1 run-time libraries. This exercised peer certificate fingerprint matching and session resumption. No major issues. The only interesting observations are: * With TLS 1.3 a new session is generated even sessions are resumed, because the server responds with a new ticket in the event of session resumption. With TLS 1.2 sessions that had sufficient remaining lifetime did not trigger new ticket generation on the server, and no new session was stored on the client. This causes needless wear-and-tear on the external session cache in Postfix, since each connection writes out a new session, replacing the one it just used. Some might consider this a security feature, but it is not especially desirable with SMTP. Any thoughts about whether this could be tunable? It would have to be server-side tuning I think, since the client does not know why the server issued a new session, perhaps the old one was not (or will soon not) be valid for re-use. * Postfix logs a warning when the compile-time and runtime libraries are not exactly the same (once per process start), this is expected. Perhaps we should provide a means for users to turn that off. * The Postfix logging from the new session callback precedes the OpenSSL message callback that a session ticket was received from the server. It seems that the OpenSSL message callback happens at the completion of session ticket processing, but this results in slightly surprising ordering of the logs. It seems as though the session is stored before the ticket arrives. I think this "cosmetic" issue may be worth addressing. - Client-side diagnostics - posttls-finger: warning: run-time library vs. compile-time header version mismatch: OpenSSL 1.1.1 may not be compatible with OpenSSL 1.1.0 posttls-finger: SSL_connect:before SSL initialization posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS read server hello posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions posttls-finger: SSL_connect:SSLv3/TLS read server certificate posttls-finger: SSL_connect:TLSv1.3 read server certificate verify posttls-finger: SSL_connect:SSLv3/TLS read finished posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec posttls-finger: SSL_connect:SSLv3/TLS write finished posttls-finger: Verified TLS connection established to 127.0.0.1[127.0.0.1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) posttls-finger: SSL_connect:SSL negotiation finished successfully posttls-finger: SSL_connect:SSL negotiation finished successfully posttls-finger: save session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D to memory cache posttls-finger: SSL_connect:SSLv3/TLS read server session ticket posttls-finger: Reconnecting after 1 seconds posttls-finger: looking for session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D in memory cache posttls-finger: reloaded session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D from memory cache posttls-finger: SSL_connect:before SSL initialization posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS read server hello posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions posttls-finger: SSL_connect:SSLv3/TLS read finished posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec posttls-finger: SSL_connect:SSLv3/TLS write finished posttls-finger: 127.0.0.1[127.0.0.1]:25: Reusing old session posttls-finger: Verified TLS connection established to 127.0.0.1[127.0.0.1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) posttls-finger: SSL_connect:SSL negotiation finished successfully posttls-finger: SSL_connect:SSL negotiation finished successfully posttls-finger: save session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D to memory cache posttls-finger: SSL_connect:SSLv3/TLS read server session ticket - End - -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test
On 23/04/18 02:49, Viktor Dukhovni wrote: > > I tested a Postfix server and client built against OpenSSL 1.1.0, > using 1.1.1 run-time libraries. This exercised peer certificate > fingerprint matching and session resumption. No major issues. > > The only interesting observations are: > > * With TLS 1.3 a new session is generated even sessions are > resumed, because the server responds with a new ticket > in the event of session resumption. With TLS 1.2 sessions > that had sufficient remaining lifetime did not trigger new > ticket generation on the server, and no new session was > stored on the client. This causes needless wear-and-tear > on the external session cache in Postfix, since each > connection writes out a new session, replacing the one > it just used. Some might consider this a security feature, > but it is not especially desirable with SMTP. Any thoughts > about whether this could be tunable? It would have to be > server-side tuning I think, since the client does not know > why the server issued a new session, perhaps the old one > was not (or will soon not) be valid for re-use. Note that some servers may actually issue more than one ticket per connection. Notably boring issues 2 by default. I'm not sure if they enable configuration of that. In servers that accept early data we enforce single use tickets. In those scenarios it may make sense to have more than one ticket issued per connection. I do have a WIP PR for enabling configuration of the number of tickets to be sent on the server side: https://github.com/openssl/openssl/pull/5227 I have not been prioritising that at the moment because I have been focussing more on fixing defects. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] When to enable TLS 1.3
> On Apr 22, 2018, at 12:16 PM, Richard Levitte wrote: > > openssl-users> > We are considering if we should enable TLS 1.3 by default or > not, > openssl-users> > or when it should be enabled. For that, we would like to > know how > openssl-users> > applications behave with the current version. > openssl-users> > openssl-users> It is perhaps unclear in the last sentence what "the current > version" > openssl-users> means. > > I took that to mean "the 1.1.0 series" I meant unclear to potential readers, rather than project maintainers. :-) -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] When to enable TLS 1.3
In message <431270c5-3da3-4a9d-9292-12adc46cc...@dukhovni.org> on Sat, 21 Apr 2018 14:45:34 -0400, Viktor Dukhovni said: openssl-users> > We are considering if we should enable TLS 1.3 by default or not, openssl-users> > or when it should be enabled. For that, we would like to know how openssl-users> > applications behave with the current version. openssl-users> openssl-users> It is perhaps unclear in the last sentence what "the current version" openssl-users> means. I took that to mean "the 1.1.0 series" -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
