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

Dmitry Belyavsky beldmit at gmail.com
Fri Sep 14 10:30:00 UTC 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180914/65776f7a/attachment-0001.html>


More information about the openssl-users mailing list