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

Martin Thomson <mt@lowentropy.net> Tue, 09 May 2023 00:24 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2EFE5C169536; Mon, 8 May 2023 17:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.796
X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b="cwfyZo67"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="IswpzkvH"
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AuhUQEvxu3AH; Mon, 8 May 2023 17:24:13 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29027C16953B; Mon, 8 May 2023 17:24:13 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 97D725C00D5; Mon, 8 May 2023 20:24:10 -0400 (EDT)
Received: from imap41 ([]) by compute6.internal (MEProxy); Mon, 08 May 2023 20:24:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1683591850; x=1683678250; bh=DjLhh6lfCDfyZDegIHgaBcXNT4BI+cU8CC7 pZlWq3Ik=; b=cwfyZo67gLw/mOG5uv96XCcgtrJotuG5kI0+7UWzdtgLyrdqXQV E9qN+Rtk8eGIxbo6fk4WZj3JO+Zu2+ndmmpBqW1QtRvRLwKmC+cL9htcr6vtTjgo sJHULDI+DfK3o+NW9PW/dJJQNmanj4cZsQMEfIwGVwdxYgR7XBaryWM4uP+vKbpU +767qk1roFmSHxkcZQ3xw9f2S99q35XE451/yw1zv7Sw+AXyr8mGbrWZhZnFoM1R NCBeNcXf4CpVF61IJndpCYr5OMatdUBQOhdKSqCuPFvv+OpBA7Koo0FSPVv9E9QF 1rwaW8+TN3Hodci23GSsDxm1RSC6HPHSmcQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1683591850; x= 1683678250; bh=DjLhh6lfCDfyZDegIHgaBcXNT4BI+cU8CC7pZlWq3Ik=; b=I swpzkvH/5HctsXYhTvxSSWBPObr5yEmMtWo1ABOv/AnscZsRpugNBGDJZzoxYYGN zjo/9BiOB0MAf3fik0evHvn36hee9c50NEGKXu9G4uYFpGzcJVDQsrlNLtF+S1UH zqSw2rlaU4J6pBai+U7HR2o+5KzuWeFqDBRCgS9N2EOSjdCTPvRDde6pqmWbJP17 20zQGfxGL1F26Vi0pF5qmpZnDfhikNueD5khl90B85J3MGLZl6aLni5KJ0JM677y tJuHAMLBCfMPsb+ZiBXGnPRn3TuZhzxCEgdw9wBYm7HL6Ly4P9as1/g+edtk+Ihs HG5hCmWGNKYQn0PzSHw4A==
X-ME-Sender: <xms:qpJZZMsgyPtuXGmJ6q9QtLt6fRbaU5zfBMiObt5ueuwTLrXJPRqcXA> <xme:qpJZZJd0xo4gWPZJ6thZD_lqhZusuWwc8t31ZMGUJUJUSP-qeC52ednEIrQFQAj7M RlrrT9UlxWi_qJ2F_U>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeefledgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhephfefudetteffkedvte fhueejvdeutdevieelveevgfektdetheejveeikeeggfdtnecuffhomhgrihhnpehivght fhdrohhrghdpfhhirhgvvgihvgdrtghomhdpihhrthhfrdhorhhgnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvth
X-ME-Proxy: <xmx:qpJZZHym03slLUjkTXfTYFcb4Y48xxZ-WGE3Bx7oeEcwcmbuh192iQ> <xmx:qpJZZPO25CdsJlK55OFT1HOEzMc_RaMJkSjdtiL9BLL39vdqKIGc2A> <xmx:qpJZZM_7BxdZdnFXnnKfUv5AvJdywFz2fHo0NUQP2MP8ZEdrNIVI_w> <xmx:qpJZZFIDlrzI6RdLT7pzjHglvoX9STX4cdEf8ziA296n7zOruYcOWA>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 592BD234007B; Mon, 8 May 2023 20:24:10 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-415-gf2b17fe6c3-fm-20230503.001-gf2b17fe6
Mime-Version: 1.0
Message-Id: <68a78e2c-1510-48ed-9644-2e81c5f66d53@betaapp.fastmail.com>
In-Reply-To: <GVXPR07MB967862CF57FEC0EB180C75F789719@GVXPR07MB9678.eurprd07.prod.outlook.com>
References: <168329718302.50127.18120629996969657@ietfa.amsl.com> <GVXPR07MB96781F20D284D7C999F7BBA789729@GVXPR07MB9678.eurprd07.prod.outlook.com> <343a4bf1-7a57-0084-5280-1556c9da4c36@huitema.net> <GVXPR07MB967862CF57FEC0EB180C75F789719@GVXPR07MB9678.eurprd07.prod.outlook.com>
Date: Tue, 09 May 2023 10:23:50 +1000
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org, tls@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CVBujQ36CS9B7nMoHj5G-iv0IpE>
Subject: [TLS] Weakly authenticated ciphers (was about draft-mattsson-cfrg-aes-gcm-sst)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 May 2023 00:24:18 -0000

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.


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 <cfrg-bounces@irtf.org> on behalf of Christian Huitema 
> <huitema@huitema.net>
> *Date: *Sunday, 7 May 2023 at 20:07
> *To: *John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, IRTF 
> CFRG <cfrg@irtf.org>, sframe@ietf.org <sframe@ietf.org>, moq@ietf.org 
> <moq@ietf.org>
> *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: internet-drafts@ietf.org <internet-drafts@ietf.org>
>> Date: Friday, 5 May 2023 at 16:33
>> To: John Mattsson <john.mattsson@ericsson.com>, Alexander Maximov <alexander.maximov@ericsson.com>, John Mattsson <john.mattsson@ericsson.com>, Matt Campagna <campagna@amazon.com>, Matthew Campagna <campagna@amazon.com>
>> 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
> CFRG@irtf.org
> 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