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.d...@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:beld...@gmail.com] > *Sent:* Wednesday, 12 September 2018 7:02 PM > *To:* openssl-users@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
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
