Re: Unexpected EOF handling

2020-05-08 Thread Kurt Roeckx
On Fri, May 08, 2020 at 01:27:00PM +0300, Dmitry Belyavsky wrote:
> On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx  wrote:
> >
> > So I think the suggestion is to have this:
> > - By default, SSL_ERROR_SSL is returned with
> >   SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be
> >   marked invalid.
> > - With an option, SSL_ERROR_ZERO_RETURN is returned, the session
> >   will stay valid.
> >
> 
> If I remember correctly, session resumption is a way to significantly
> reduce a server's workload.
> So I think that by default (and maybe the only option) we should prefer the
> old behaviour.

If it's a fatal error, the session should be marked as bad. So if
you want that by default we don't mark is as bad, the default
should be that it's a non-fatal error, and we don't want to return
SSL_ERROR_ZERO_RETURN by default.

SSL_ERROR_SYSCALL with errno 0 does not look like a good long term
API to indicate a non-fatal error. And a different error is
also not what people want.


Kurt



Re: Unexpected EOF handling

2020-05-08 Thread Kurt Roeckx
On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
> > 
> > On 07/05/2020 12:22, Kurt Roeckx wrote:
> > > So I think we need at least to agree on:
> > > - Do we want an option that makes the unexpected EOF either a fatal
> > >   error or a non-fatal error?
> > > - Which error should we return?
> > 
> > This is an excellent summary of the current situation.
> > 
> > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a
> > long term solution. It's a very confusing API for new applications to
> > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except
> > when its not. SSL_ERROR_SYSCALL should mean fatal error.
> > 
> > That said I also recognise that it is apparently commonplace to shut
> > down a TLS connection without sending close_notify - despite what the
> > standards may say about it (and TBH we can hardly claim the moral
> > high
> > ground here since s_server does exactly this - or at least it does in
> > 1.1.1 and did until very recently in master).
> > 
> > But we do have to consider usages beyond HTTPS. I have no idea if
> > this
> > occurs in other settings or not.
> > 
> > Perhaps what we need is an option for "strict shutdown". With strict
> > shutdown "off" we could treat EOF as if we had received a
> > close_notify
> > gracefully (and don't invalidate the session). Presumably existing
> > code
> > would be able to cope with that???
> 
> Yes, existing code would be able to cope with that with one important
> exception that I am going to talk about below.
> 
> > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in
> > master).
> > 
> > I'm not sure though what the default should be.
> 
> In case we go with this solution, which would be acceptable I think, we
> MUST NOT EVER make it the default because existing applications that
> depend on the existing way how the unclean EOF condition is returned
> might actually depend on it to detect the truncation attack.

I agree that we should not return SSL_ERROR_ZERO_RETURN by default
on an unexpected EOF.

If the default behaviour should be to make it a non-fatal error,
like the old behaviour is, I would really prefer a different
error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL.

So I think the suggestion is to have this:
- By default, SSL_ERROR_SSL is returned with
  SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be
  marked invalid.
- With an option, SSL_ERROR_ZERO_RETURN is returned, the session
  will stay valid.


Kurt




Re: Unexpected EOF handling

2020-05-08 Thread Dmitry Belyavsky
Dear Kurt

On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx  wrote:

> On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> > On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote:
> > >
> > > On 07/05/2020 12:22, Kurt Roeckx wrote:
> > > > So I think we need at least to agree on:
> > > > - Do we want an option that makes the unexpected EOF either a fatal
> > > >   error or a non-fatal error?
> > > > - Which error should we return?
> > >
> > > This is an excellent summary of the current situation.
> > >
> > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a
> > > long term solution. It's a very confusing API for new applications to
> > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except
> > > when its not. SSL_ERROR_SYSCALL should mean fatal error.
> > >
> > > That said I also recognise that it is apparently commonplace to shut
> > > down a TLS connection without sending close_notify - despite what the
> > > standards may say about it (and TBH we can hardly claim the moral
> > > high
> > > ground here since s_server does exactly this - or at least it does in
> > > 1.1.1 and did until very recently in master).
> > >
> > > But we do have to consider usages beyond HTTPS. I have no idea if
> > > this
> > > occurs in other settings or not.
> > >
> > > Perhaps what we need is an option for "strict shutdown". With strict
> > > shutdown "off" we could treat EOF as if we had received a
> > > close_notify
> > > gracefully (and don't invalidate the session). Presumably existing
> > > code
> > > would be able to cope with that???
> >
> > Yes, existing code would be able to cope with that with one important
> > exception that I am going to talk about below.
> >
> > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in
> > > master).
> > >
> > > I'm not sure though what the default should be.
> >
> > In case we go with this solution, which would be acceptable I think, we
> > MUST NOT EVER make it the default because existing applications that
> > depend on the existing way how the unclean EOF condition is returned
> > might actually depend on it to detect the truncation attack.
>
> I agree that we should not return SSL_ERROR_ZERO_RETURN by default
> on an unexpected EOF.
>
> If the default behaviour should be to make it a non-fatal error,
> like the old behaviour is, I would really prefer a different
> error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL.
>
> So I think the suggestion is to have this:
> - By default, SSL_ERROR_SSL is returned with
>   SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be
>   marked invalid.
> - With an option, SSL_ERROR_ZERO_RETURN is returned, the session
>   will stay valid.
>

If I remember correctly, session resumption is a way to significantly
reduce a server's workload.
So I think that by default (and maybe the only option) we should prefer the
old behaviour.

-- 
SY, Dmitry Belyavsky


Re: Alpha2

2020-05-08 Thread Richard Levitte
You might want to consider reviewing #11630, an reminding me what else
needs to get fixed in there.

On Fri, 08 May 2020 10:55:19 +0200,
Matt Caswell wrote:
> 
> Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss
> current progress. It was proposed that we should do the Alpha 2 release
> next week (on Thursday 14th May). Unless I hear objections otherwise, I
> plan to go with that.
> 
> Matt
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/


Re: Alpha2

2020-05-08 Thread Dmitry Belyavsky
Dear Matt,

The workaround for the 11763 is implemented, 11764 seems to be fixed now,
so no objections from my side.
Happy weekend!

On Fri, May 8, 2020 at 11:58 AM Dmitry Belyavsky  wrote:

> Dear Matt,
>
> I kindly ask not to make release until issues raised in #11763 and #11764
> are fixed.
>
> On Fri, May 8, 2020 at 11:55 AM Matt Caswell  wrote:
>
>> Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss
>> current progress. It was proposed that we should do the Alpha 2 release
>> next week (on Thursday 14th May). Unless I hear objections otherwise, I
>> plan to go with that.
>>
>> Matt
>>
>
>
> --
> SY, Dmitry Belyavsky
>


-- 
SY, Dmitry Belyavsky


Re: OMC Vote on deprecation of command line apps

2020-05-08 Thread Dr Paul Dale
This vote has passed: 3 for, 1 against and 2 abstentions.

Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 8 May 2020, at 3:08 pm, Dr Paul Dale  wrote:
> 
> PR 11575  has been blocking 
> awaiting decision for a while now.  Time for a vote:
> 
> topic: Merge #11575 for 3.0.
> comment: This PR removes the notes indicating that a number of the command
>  line utilities are deprecated.  Not merging it will leave them 
> flagged
>  as deprecated.
> Proposed by: Paul Dale
> Public: yes
> opened: 2020-05-08
> 
> Ideally we’ll have a decision in time for the next 3.0 alpha release.
> 
> 
> The crux of the matter is that a number of the command line utilities are 
> flagged as deprecated currently:
> dhparam
> dsa
> dsaparam
> ec
> ecparam
> agendas
> rsa
> These commands are not being removed in 3.0, instead they’ve been rewritten 
> to use the PKEY APIs instead of the low level APIs as far as possible.
> 
> 
> The reasons for keeping them are:
> they are easier to use than the pkey replacements
> a web search will likely result in thees commands not the pkey replacements.
> 
> The reason for removing them is one of maintenance: having duplicate commands 
> means having to make changes in two places and this has been missed in the 
> past and will be in the future.
> 
> 
> Other random notes:
> Deprecation of these commands does not mandate that they are removed at the 
> first opportunity.  It only indicates that we want to move away from them.
> Rewriting these commands so that they call the pkey replacements looks to be 
> very difficult.  Reproducing the exact behaviours will be challenging, 
> although the basic functionality would be straightforward.
> The rsautl command is deprecated and isn’t slated for being restored — 
> pkeyutl is every bit as easy to use.
> The -dsaparam option to dhparam is deprecated — it cannot be supported 
> without direct access to low level functionality we want to remove.
> Post quantum crypto will make the discussion obsolete — none of these 
> algorithms are useful in a quantum computer world.
> 
> My personal opinion is that these commands are good being deprecated but that 
> we should not remove them until their usefulness is at an end.  This will 
> likely mean not removing them after five years of deprecation.  It would mean 
> removing them once quantum computers are shown to be effective.  Without 
> deprecation now, we can’t remove them until a lot later.
> 
> 
> Pauli
> -- 
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
> Phone +61 7 3031 7217
> Oracle Australia
> 
> 
> 
> 



Alpha2

2020-05-08 Thread Matt Caswell
Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss
current progress. It was proposed that we should do the Alpha 2 release
next week (on Thursday 14th May). Unless I hear objections otherwise, I
plan to go with that.

Matt


Re: Alpha2

2020-05-08 Thread Dmitry Belyavsky
Dear Matt,

I kindly ask not to make release until issues raised in #11763 and #11764
are fixed.

On Fri, May 8, 2020 at 11:55 AM Matt Caswell  wrote:

> Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss
> current progress. It was proposed that we should do the Alpha 2 release
> next week (on Thursday 14th May). Unless I hear objections otherwise, I
> plan to go with that.
>
> Matt
>


-- 
SY, Dmitry Belyavsky