[openssl-users] Limit the number of AES-GCM keys allowed in TLS

[Kyle Hamilton]

...and once again FIPS screws those who don't want to adhere to its
mandates (which everyone in the know has always stated simply reduces
security by requiring the use of less-secure ciphers and implementations,
without allowing patches or modifications to deal with newly-discovered
classes of attacks without requiring a complete new validation procedure).

Also, I fear that I am likely to be viewed as "overly paranoid" here, by
reminding everyone that Oracle exists because CIA wanted a way to avoid
paying IBM more money.  They have maintained their national-security roots
("Trusted Oracle", anyone?), and both US and Australia are members of the
Five Eyes coalition; there's no reason that governments wouldn't lean on
their assets which hire contributors to OpenSSL to reduce the putative
security level that OpenSSL could provide, via platitudes of the form "the
check will be cheaper".  (It was in the Snowden docs, after all, that the
US government has wealened encryption by sabotaging standardization efforts
and open-source particopation.  I have no doubt that governments within
Five Eyes want to decrease the number of keys they have to crack in traffic
that they don't already know the profile of.)

I really think that the checks should be conditional on FIPS mode or
setting an option flag (for those national standards that don't have a
validation effort associated with them).

-Kyle H

On Sun, Sep 16, 2018, 14:23 Paul Dale <paul.dale at oracle.com> wrote:

> There is nothing S390 specific in this, it is a requirement to use GCM
> based ciphers for TLS when running in a FIPS validated environment.  The
> check will be cheaper than trying to avoid it by conditioning on FIPS mode
> -- hence it’s unconditional.
>
>
>
>
>
> Pauli
>
> --
>
> Oracle
>
> Dr Paul Dale | Cryptographer | Network Security & Encryption
>
> Phone +61 7 3031 7217
>
> Oracle Australia
>
>
>
> *From:* Dmitry Belyavsky [mailto:beldmit at gmail.com]
> *Sent:* Friday, 14 September 2018 8:41 PM
> *To:* openssl-users at openssl.org
> *Subject:* Re: [openssl-users] Limit the number of AES-GCM keys allowed
> in TLS
>
>
>
> Hello,
>
>
>
> Sorry, I've just found similar checks in all _CGM functions.
>
>
>
> On Fri, Sep 14, 2018 at 1:30 PM Dmitry Belyavsky <beldmit at gmail.com>
> wrote:
>
> Dear Paul,
>
>
>
> Could you please clarify?
>
> The code seems to be related to s390 platform. Do I miss something?
>
>
>
> On Thu, Sep 13, 2018 at 1:55 AM Paul Dale <paul.dale at oracle.com> wrote:
>
> I wasn’t aware of other national standards requiring a similar check.
>
>
>
> I made the change in the AES-GCM code because FIPS demands the check be
> inside the FIPS boundary.  I’d have preferred to make it in the TLS layer,
> but that mustn’t be inside the FIPS boundary.  My understanding is that TLS
> catches this case earlier and thus the test can never pass.
>
>
>
> I don’t think dropping the check down into the algorithm implementations
> makes sense.  A more generic mechanism at the EVP would.
>
>
>
>
>
>
>
> Pauli
>
> --
>
> Oracle
>
> Dr Paul Dale | Cryptographer | Network Security & Encryption
>
> Phone +61 7 3031 7217
>
> Oracle Australia
>
>
>
> *From:* Dmitry Belyavsky [mailto:beldmit at gmail.com]
> *Sent:* Wednesday, 12 September 2018 7:02 PM
> *To:* openssl-users at openssl.org
> *Subject:* [openssl-users] Limit the number of AES-GCM keys allowed in TLS
>
>
>
> Hello,
>
>
>
> The issue https://github.com/openssl/openssl/pull/7129 has introduced a
> possibility to limit the amount of TLS records processed without key
> changing as required by FIPS.
>
>
>
> We in Russia have limitations with the same semantics applicable to
> Russian GOST TLS ciphersuites (
> https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/) so
> I think that this mechanism is very useful.
>
>
>
> The current implementation is done at EVP level, and it seems suboptimal
> because of the following reasons:
>
> - If the AES implementation is provided via engine, not by OpenSSL itself,
> the limitation can be avoided
>
> - the limitation has been made too generic
>
> - the implementation seems to be AEAD-specific.
>
>
>
> So does not it make sense to provide this limitation at least at the
> ciphersuite level? It can provide more straightforward way to manage such
> limitations.
>
>
> Thank you!
>
>
>
> --
>
> SY, Dmitry Belyavsky
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180917/cc035e58/attachment-0001.html>