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

[John Mattsson <[e-mail]>]

Hi Martin,

It is true that with the current construction, the short tags would be used also in the TLS 1.3 handshake, but it is worth noting that the TLS 1.3 handshake is built on SIGMA-I where the security proof is done without the AEAD. The AEAD in the SIGMA-I handshake is for confidentiality. TLS 1.3 have giant (256- and 384-bit) MACs in the finished messages and the tickets have their own independent security. I don't see any big impact looking at it quickly.

That said, I don't have any interest in driving short tags for general applications. I think it would be useful in specialized use cases like MoQ only. It is a bit uncertain which protocols will be used in the future. Long-term, QUIC might replace not only most use of TLS and DTLS, but also SCTP and SRTP.

Martin Thompson wrote:
>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).
That seems like a good idea and a requirement if you are also sending application data with higher security requirements.

Cheers,
John

From: TLS <[e-mail]> on behalf of Martin Thomson <[e-mail]>
Date: Tuesday, 9 May 2023 at 02:25
To: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [TLS] Weakly authenticated ciphers (was about draft-mattsson-cfrg-aes-gcm-sst)
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

_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls