[TLS] Weakly authenticated ciphers (was about draft-mattsson-cfrg-aes-gcm-sst)

[Martin Thomson <[e-mail]>]

I like the idea that we might have a more efficient cipher in this particular way.  I've been a fan of OCB for that reason for some time.

However, I don't think that QUIC or TLS integration is necessarily a good idea for this cipher.  SRTP is one thing, but QUIC and TLS have an entirely different structure that might make short tags more risky than otherwise.

DTLS-SRTP has a split structure, with the important key agreement piece being done with a full (D)TLS handshake.  The handshake is typically protected with ciphers that have strong protections against forgery.  In a context where you have signaling or data transfer (like WebRTC data channels), that data is also protected by the stronger cipher.  Individual media streams are then protected with a different cipher, in SRTP.  For instance, you might protect audio with one of the truncated HMAC modes.

Now, setting aside the bit where it is ridiculous to insist on shaving a few bytes off packets when you have a multi-megabit video flow alongside, weaker protections can be useful.  Authentication is a non-trivial proportion of the overall cost of sending audio, especially when you want to keep packet rates high to reduce latency.  More so when you consider the potential to have multiple layers of protection (SFrame), potentially with different tolerance to forgery on each.

Choosing a weak cipher (and we should not pretend that this is anything but that) means that any weakness affects everything on a connection.  That isn't good for QUIC or TLS.

It might be possible to build a QUIC extension that allowed some data to be protected differently than other (perhaps using connection IDs; a popular technique).  For me, I'd need something like that for this cipher to find a role in QUIC.  To that end, I have no interest in negotiating this cipher for use in TLS proper.

Cheers,
Martin

On Tue, May 9, 2023, at 06:53, John Mattsson wrote:
> Hi Christian,
> 
> Yes, sending to the quic list is a good idea. I think QUIC is likely to 
> be used in a huge number of future use cases. Secure short tags might 
> be interesting for more use cases than Media over QUIC.
> 
> Christian Huitema wrote:
>>If the "short tags" can save per packet overhead while maintaining security properties
>
> The short tags do increase the forgery probability. The security is only
> ideal with respect to the tag length. For general applications like HTTP/3
> I think you would like to keep the forgery probability per packet close to
> the current level.
> 
> In QUIC my understanding is that the maximum plaintext is 2^12 128-bit 
> blocks and the length of the associated data is negligible. The 
> security level of the 128-bit AES-GCM tags is therefore t – log2(n + m 
> + 1) ≈ 128 - 12 = 116 bits.
> 
> With AES-GCM-SST in QUIC you would get ideal forgery probability ≈ 2^-t 
> for tags of length t <= 14 bytes. 
> 
> Cheers,
> John
> 
> *From: *CFRG <[e-mail]> on behalf of Christian Huitema 
> <[e-mail]>
> *Date: *Sunday, 7 May 2023 at 20:07
> *To: *John Mattsson <john.mattsson=[e-mail]>, IRTF 
> CFRG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] 
> <[e-mail]>
> *Subject: *Re: [CFRG] [Moq] FW: New Version Notification for 
> draft-mattsson-cfrg-aes-gcm-sst-00.txt
> John,
>
> You should probably send this to the QUIC list as well. Media over QUIC 
> is just one application of QUIC. If the "short tags" can save per packet 
> overhead while maintaining security properties, then they are 
> interesting for many QUIC applications.
>
> -- Christian Huitema
>
> On 5/5/2023 7:45 AM, John Mattsson wrote:
>> Hi,
>> 
>> We just submitted draft-mattsson-cfrg-aes-gcm-sst-00. Advanced Encryption Standard (AES) with Galois Counter Mode with Secure Short Tags (AES-GCM-SST) is very similar to AES-GCM but have short tags with forgery probabilities close to ideal. The changes to AES-GCM were suggested by Nyberg et al. in 2005 as a comment to NIST and are based on proven theoretical constructions.
>> 
>> AES-GCM performance with secure short tags have many applications, one of them is media encryption. Audio packets are small, numerous, and ephemeral, so on the one hand, they are very sensitive in percentage terms to crypto overhead, and on the other hand, forgery of individual packets is not a big concern.
>> 
>> Cheers,
>> John
>> 
>> From: [e-mail] <[e-mail]>
>> Date: Friday, 5 May 2023 at 16:33
>> To: John Mattsson <[e-mail]>, Alexander Maximov <[e-mail]>, John Mattsson <[e-mail]>, Matt Campagna <[e-mail]>, Matthew Campagna <[e-mail]>
>> Subject: New Version Notification for draft-mattsson-cfrg-aes-gcm-sst-00.txt
>> 
>> A new version of I-D, draft-mattsson-cfrg-aes-gcm-sst-00.txt
>> has been successfully submitted by John Preuß Mattsson and posted to the
>> IETF repository.
>> 
>> Name:           draft-mattsson-cfrg-aes-gcm-sst
>> Revision:       00
>> Title:          Galois Counter Mode with Secure Short Tags (GCM-SST)
>> Document date:  2023-05-05
>> Group:          Individual Submission
>> Pages:          16
>> URL:            https://www.ietf.org/archive/id/draft-mattsson-cfrg-aes-gcm-sst-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-mattsson-cfrg-aes-gcm-sst/
>> Html:           https://www.ietf.org/archive/id/draft-mattsson-cfrg-aes-gcm-sst-00.html
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-mattsson-cfrg-aes-gcm-sst
>> 
>> 
>> Abstract:
>>     This document defines the Galois Counter Mode with Secure Short Tags
>>     (GCM-SST) Authenticated Encryption with Associated Data (AEAD)
>>     algorithm.  GCM-SST can be used with any keystream generator, not
>>     just a block cipher.  The main differences compared to GCM [GCM] is
>>     that GCM-SST uses an additional subkey Q, that fresh subkeys H and Q
>>     are derived for each nonce, and that the POLYVAL function from AES-
>>     GCM-SIV is used instead of GHASH.  This enables short tags with
>>     forgery probabilities close to ideal.  This document also registers
>>     several instances of Advanced Encryption Standard (AES) with Galois
>>     Counter Mode with Secure Short Tags (AES-GCM-SST).
>> 
>>     This document is the product of the Crypto Forum Research Group.
>> 
>> 
>> 
>> 
>> The IETF Secretariat
>> 
>> 
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-9034b67a44f3143f&q=1&e=59d3bb57-6543-430e-8ba2-f3a9248d7619&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg