Re: OMC Vote on deprecation of command line apps

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

Re: Alpha2

[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

[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: Unexpected EOF handling

[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

[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: Unexpected EOF handling

[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: Alpha2

[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

Alpha2

[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