Re: [openssl-project] Removal of NULL checks
I'm firmly in the don't remove them camp too. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -Original Message- From: Viktor Dukhovni [mailto:openssl-us...@dukhovni.org] Sent: Wednesday, 8 August 2018 11:52 PM To: openssl-project@openssl.org Subject: Re: [openssl-project] Removal of NULL checks > On Aug 8, 2018, at 6:19 AM, Tim Hudson wrote: > > However in the context of removing such checks - that we should not be > doing - the behaviour of the APIs in this area should not be changed Should not be changed period. Even across major release boundaries. This is not an ABI compatibility issue, it is a source compatibility issue, and should avoided all the time. If we want to write a *new* function that skips the NULL checks it gets a new name. -- Viktor. ___ 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] EdDSA and "default_md"?
On 08/08/18 21:22, Viktor Dukhovni wrote: > Don't know whether everyone here also reads openssl-users, so to recap, > Robert Moskowitz reports considerable frustration > as a result of "default_md = sha256" being incompatible with Ed25519 > (and Ed448). He's working around this with "-md null" sprinkled about > liberally, but it is not especially intutive. > > What should we do here? Perhaps we need a "default_md = default" that > picks a sensible default for each key algorithm (sha256 typically, > but "null" for EdDSA)? Or ignore "default_md" with EdDSA, or ??? > Probably we should just ignore default_md for EdDSA. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] EdDSA and "default_md"?
Don't know whether everyone here also reads openssl-users, so to recap, Robert Moskowitz reports considerable frustration as a result of "default_md = sha256" being incompatible with Ed25519 (and Ed448). He's working around this with "-md null" sprinkled about liberally, but it is not especially intutive. What should we do here? Perhaps we need a "default_md = default" that picks a sensible default for each key algorithm (sha256 typically, but "null" for EdDSA)? Or ignore "default_md" with EdDSA, or ??? -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Removal of NULL checks
On Wed, Aug 08, 2018 at 08:19:24PM +1000, Tim Hudson wrote: > We don't have a formal policy of no NULL checks - we just have a few > members that think we should have such a policy but it has never been voted > on as we had sufficiently varying views for a consensus approach to not be > possible. > > Personally I'm in favour of high-level APIs having NULL checks as it (in my > experience) leads to less bogus error crash reports from users and simpler > handling in error cleanup logic. > Otherwise you end up writing a whole pile of if(x!=NULL) FOO_free(x); etc I think at least Rich would not add checks for NULL in functions that don't expect to be called with NULL, but on the other hand moves the NULL check into the free() calls. But in that case, we also clearly document that it can be called with NULL. So it's at least not general that there shouldn't be a NULL check. Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Removal of NULL checks
> On Aug 8, 2018, at 6:19 AM, Tim Hudson wrote: > > However in the context of removing such checks - that we should not be doing > - the behaviour of the APIs in this area should not be changed Should not be changed period. Even across major release boundaries. This is not an ABI compatibility issue, it is a source compatibility issue, and should avoided all the time. If we want to write a *new* function that skips the NULL checks it gets a new name. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Reuse of PSKs between TLSv1.2 and TLSv1.3
For the full background to this issue see: https://github.com/openssl/openssl/issues/6490 TL;DR summary: The TLSv1.2 and TLSv1.3 PSK mechanisms are quite different to each other. OpenSSL (along with at least GnuTLS maybe others) has implemented an upgrade path which enables the reuse of a TLSv1.2 PSK in TLSv1.3. This is not prohibited by the spec. David Benjamin has raised concerns about this due to key separation. Everything else in TLSv1.3 is provably secure - but this is not. The spec has been updated to add some words of warning about this. There seems to be two schools of thought on what to do about this: 1) We should seek to avoid this risk. As a fix we should disable TLSv1.3 if TLSv1.2 PSKs have been configured. We expect that at some later time the IETF will come up with a better answer and when that happens we can implement it then. A PR to do the removal is here: https://github.com/openssl/openssl/pull/6836 2) This is a theoretical risk - there might not actually be a problem at all, its just that we can't prove it. OTOH not upgrading to TLSv1.3 is definitely a bad thing, so we should just leave things as they are and accept the theoretical risk. I'll admit that I've been flip-flopping between the two approaches to this and there doesn't seem to be a clear consensus forming. How should we take this forward? Does it require an OMC vote? Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Removal of NULL checks
We don't have a formal policy of no NULL checks - we just have a few members that think we should have such a policy but it has never been voted on as we had sufficiently varying views for a consensus approach to not be possible. Personally I'm in favour of high-level APIs having NULL checks as it (in my experience) leads to less bogus error crash reports from users and simpler handling in error cleanup logic. Otherwise you end up writing a whole pile of if(x!=NULL) FOO_free(x); etc But it is a style issue. However in the context of removing such checks - that we should *not* be doing - the behaviour of the APIs in this area should not be changed outside of a major version increment - and even then I would not make the change either because it introduces changes which in themselves serve no real purpose - i.e. a style change can result in making a program that used to work fine crash in bad ways - and that we shouldn't be doing even across major version increments in my view. Tim. On Wed, Aug 8, 2018 at 8:08 PM, Matt Caswell wrote: > We've had a policy for a while of not requiring NULL checks in > functions. However there is a difference between not adding them for new > functions and actively removing them for old ones. > > See https://github.com/openssl/openssl/pull/6893 > > In this case the removal of a NULL check in the stack code had the > unintended consequence of a crash in a no-comp build. Is it wise to be > actively removing existing NULL checks like this? It does have an impact > on the behaviour of a function (even if that behaviour is undocumented > and not encouraged). The concern I have is for our API/ABI compatibility > guarantee. If we make changes like this then 1.1.1 may no longer be a > drop in replacement for 1.1.0 for some apps. > > Matt > > ___ > 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
[openssl-project] Removal of NULL checks
We've had a policy for a while of not requiring NULL checks in functions. However there is a difference between not adding them for new functions and actively removing them for old ones. See https://github.com/openssl/openssl/pull/6893 In this case the removal of a NULL check in the stack code had the unintended consequence of a crash in a no-comp build. Is it wise to be actively removing existing NULL checks like this? It does have an impact on the behaviour of a function (even if that behaviour is undocumented and not encouraged). The concern I have is for our API/ABI compatibility guarantee. If we make changes like this then 1.1.1 may no longer be a drop in replacement for 1.1.0 for some apps. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
