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

Dmitry Belyavsky beldmit at gmail.com
Fri Sep 14 10:41:21 UTC 2018


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


More information about the openssl-users mailing list