Re: [CFRG] Update of the AEGIS draft

[Colin Perkins <[e-mail]>]

On 14 Apr 2023, at 17:05, John Mattsson wrote:

> Review of draft-irtf-cfrg-aegis-aead-02
>
> Hi,
>
> Thanks for driving this work! I have always been very supportive of this work. Reading and providing comments on the NIST SP 800-38 series during the last year has made me even more supportive. I think AEGIS fills several important requirements that are missing from current AEAD algorithms, espcially high-performance on commodity CPUs as well as large nonces. I hope the authors will submit AEGIS to the upcoming NIST workshop on encryption modes.
>
> I think the draft seems in a very good state. Some comments:
>
> - Title: Titles of RFCs should be capitalized according to RFC 7322, i.e., change to "The AEGIS Family of Authenticated Encryption Algorithms"
>
> - Abstract: I think the abstract should mention all the nice high level properties: support of large nonces, large plaintexts, key commitment…
>
> - Abstract: I think you should remove "It is not an IETF product and is not a standard." All needed text is automatically added to the RFC.

Section 2.1 of RFC 5743 requires certain statements be included in the Abstract and Introduction of IRTF drafts. This includes making it “very clear throughout the document that it is not an IETF product and is not a standard”. Having this text in the Abstract is one way of addressing that requirement, so I would not remove it.

Colin



> - "With AEGIS-128L, random nonces can safely encrypt up to 2^48 messages
>    using the same key with negligible collision probability."
>
>   Not sure 2^-33 is always considered negligible. Maybe good to inform the reader that after n messages the collision probability is n^2 / 2^129. I assume 2^48 was chosen to align with the NIST required 2^-32 probability for GCM.
>
> - IANA Considerations: How do I use AEGIS in QUIC and DTLS 1.3? Code points have been registered for TLS 1.3, which means that AEGIS can be used for TLS 1.3. It can however not be used for QUIC, DTLS 1.3, and cTLS as that requires standardization of how to do the QUIC and DTLS 1.3 Header Protection. What is the plan for that? I think this should be done very soon. Should that be done it this draft or a separate draft? Happy to help write such a separate draft/drafts if needed. The IANA registry says "DTLS-OK = Y", but that is only true for DTLS 1.2. How to encrypt the DTLS 1.3 header when TLS_AEGIS_256_SHA384 or TLS_AEGIS_128L_SHA256 is used is not specified. I would also like to see AEGIS being Recommended = 'Y' in the future. Unless done in this draft, I think a TLS WG draft should be processed in parallel with the CFRG draft doing these three things:
>
> 1. Recommended = 'Y'
> 2. How to encrypt DTLS 1.3 headers
> 3. How to encrypt QUIC headers
>
> Cheers,
> John
>
> From: CFRG <[e-mail]> on behalf of Frank Denis <cfrg=[e-mail]>
> Date: Friday, 14 April 2023 at 15:58
> To: IRTF CFRG <[e-mail]>
> Subject: [CFRG] Update of the AEGIS draft
>
> Hi all,
>
>
>
> A new revision of the draft on the AEGIS family of authenticated encryption algorithms was recently published.
>
>
>
> AEGIS is an AEAD designed for high performance applications, with significant advantages over AES-GCM:
>
> - Fast. 2x to 4x faster than AES-GCM on CPUs with AES pipelines. Software implementations also tend to be faster
>
> - Very simple to implement securely and efficiently using only the AES forward round function
>
> - Reduced memory usage: doesn’t require precomputing a key schedule nor powers of the MAC key to achieve optimal performance
>
> - Large nonce size (128 bits for AEGIS-128L, 256 bits for AEGIS-256)
>
> - Better security bounds
>
> - Context committing
>
> - Backtracking resistant
>
>
>
> In addition to internal deployments, AEGIS is already deployed in OVH routers, in the Linux kernel and in VPN software.
>
>
>
> Multiple implementations exist (C, C++, Rust, Zig, Python, Go, Assembly), most of them having been written independently, using only the specification:
>
> https://github.com/jedisct1/draft-aegis-aead#known-implementations<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-3b0fdf065dc1e6ef&q=1&e=c68cc6f1-dbc0-4c3d-8ff6-e92a201f6a59&u=https%3A%2F%2Fgithub.com%2Fjedisct1%2Fdraft-aegis-aead%23known-implementations>
>
> In addition to reference code and to the specification, Google’s Project Wycheproof includes an extensive set of test vectors for AEGIS.
>
>
>
> For evaluation purposes, AEGIS can be used as an alternative to AES-GCM in the context of TLS.
>
> In order to ensure interoperability, IANA has assigned identifiers for AEGIS-based cipher suites.
>
> There is a maintained fork of BoringSSL that supports these cipher suites. The TLS stack of the Zig standard library also supports these suites out of the box.
>
>
>
> Feedback would be very useful. We would love to see this document move forward.
>
>
>
> Direct links to the draft:
>
> - latest version (editor’s copy): https://jedisct1.github.io/draft-aegis-aead/#go.draft-irtf-cfrg-aegis-aead.html<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-7d2fee82ec540a8d&q=1&e=c68cc6f1-dbc0-4c3d-8ff6-e92a201f6a59&u=https%3A%2F%2Fjedisct1.github.io%2Fdraft-aegis-aead%2F%23go.draft-irtf-cfrg-aegis-aead.html>
>
> - datatracker page: https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead
>
>
>
> Kind regards,
>
>
>
> -Frank.

> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg