[AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15: Issue with short tags
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 02 June 2015 13:42 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE181A90A8 for <avt@ietfa.amsl.com>; Tue, 2 Jun 2015 06:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm2yo1qDujWl for <avt@ietfa.amsl.com>; Tue, 2 Jun 2015 06:42:19 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058521A9093 for <avt@ietf.org>; Tue, 2 Jun 2015 06:42:18 -0700 (PDT)
X-AuditID: c1b4fb25-f79b66d000001131-68-556db2b9d1b7
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 82.D7.04401.9B2BD655; Tue, 2 Jun 2015 15:42:17 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.210.2; Tue, 2 Jun 2015 15:42:16 +0200
Message-ID: <556DB2B8.6060307@ericsson.com>
Date: Tue, 02 Jun 2015 15:42:16 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: John Mattsson <john.mattsson@ericsson.com>, "avt@ietf.org" <avt@ietf.org>, "Igoe, Kevin M." <kmigoe@nsa.gov>, "mcgrew@cisco.com" <mcgrew@cisco.com>
References: <3C4AAD4B5304AB44A6BA85173B4675CABC80F8F9@MSMR-GH1-UEA03.corp.nsa.gov> <B8FFC532-EC77-4FC3-B141-5BC0553E81E4@nostrum.com> <3C4AAD4B5304AB44A6BA85173B4675CABC80FB8D@MSMR-GH1-UEA03.corp.nsa.gov> <E2CFAEF9-A04F-4868-9819-DCA839E0788F@nostrum.com> <75B0FAB3-532C-45FB-905B-1A650AD8DA99@ericsson.com>
In-Reply-To: <75B0FAB3-532C-45FB-905B-1A650AD8DA99@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvre7OTbmhBsfWi1u87FnJbjHh1GtW i6ur/rBbTN97jd3i06rHTA6sHlN+b2T1WNt9lc1jyZKfTB7XTv5l9ejf9ZI1gDWKyyYlNSez LLVI3y6BK6Pnx0+mgidaFcsObmJvYFyh1MXIwSEhYCLR9iqvi5ETyBSTuHBvPVsXIxeHkMBR Rokts2dAOcsYJZZ1HmMDqeIV0Jb4tfkPM4jNIqAi0b16NxOIzSZgIXHzRyNYjahAlMTUx+tY IOoFJU7OfMICMkhEYCajRPPczWANzAK+Ek/v7gVrEBZwkjj/eDMrxLbNTBKt83ezgyQ4BRwk 1v28yQjRYCExc/55KFteonnrbLArhIAuamjqYJ3AKDgLycJZSFpmIWlZwMi8ilG0OLU4KTfd yFgvtSgzubg4P08vL7VkEyMw3A9u+a26g/HyG8dDjAIcjEo8vAp8uaFCrIllxZW5hxilOViU xHk9u0JChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTB6FUibVh4XtvraxMigzWym0b42fP7U wrpNVZPNS1MlT5lN3tQ8S9egIqR4flfW1ysxxqJah9l/xSZ8OTctfqduff+xCP6aL/Zp3DKX /E+e51Bf/c5yp+U6667FZ6du/1l82WXvwq/qsu3yn36odUYt/sVQf5X9oluM+uJly4u+ZKUu NX3hkaTEUpyRaKjFXFScCACUtuXiWAIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/mlSod_EoaqZqkOoVeTlsZdNC-ds>
Cc: Tim Polk <tim.polk@nist.gov>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15: Issue with short tags
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2015 13:42:22 -0000
WG, I have seen no reactions on this email from John. To my understanding this appears to be a real issue and without anyone disputing his claims I see the way forward is to request that the authors remove the ciphers with short tags. Cheers Magnus Westerlund (As WG chair) John Mattsson skrev den 2015-05-21 17:35: > Hi, > > My previous standpoint was that usage of GCM with short tags was > acceptable if the NIST requirements were followed. Thinking more > about the usage of GCM with short tags in general and the usage of > GCM in SRTP in particular I have changed my mind. > > I do not think GCM with short tags (i.e. 64 bits) should be > standardized by IETF even if the NIST requirements are followed, in > fact I think that NIST should revise SP 800-38D. > > I strongly recommend that AEAD_AES_128_GCM_8 is removed from > draft-ietf-avtcore-srtp-aes-gcm. > > (Note that this is only about GCM with short tags. I do fully > recommend GCM for usage with 128-bit tags. I believe that with its > excellent performance and proven security, it should be the first > choice for everybody wanting an AEAD algorithm.) > > > > General usage of GCM with short tags: > > Regarding the general usage of GCM with short tags, I wrote a paper > suggesting improvements to, and analyzing the complexity of, > Ferguson’s method for authentication key recovery. In summary the > security level (i.e. the effective key lengths) for GCM with 64-bit > tags are 70–75 bits, far below not only the current NIST requirement > of 112-bit security, but also the old NIST requirement of 80-bit > security. > > https://eprint.iacr.org/2015/477 > > Note that draft-ietf-avtcore-srtp-aes-gcm-15 does not follow the NIST > requirements, it choses deliberately to ignore them. This means that > the security level for 64-bit tags against authentication key > recovery is only 64 bits, down from the already low 70–75 bits > offered by the NIST specification. > > > > Usage of GCM with short tags in SRTP: > > Regarding the usage of GCM in SRTP, Appendix C of SP 800-38D lists > several guidelines for protocols using GCM with short tags. Two of > these guidelines are that AAD should be limited to necessary header > information and that protocols should not provide feedback regarding > the integrity of individual packets. NIST then makes the statement: > “An example of a protocol that meets these guidelines is Secure > Real-time Transport Protocol carrying Voice over Internet Protocol, > running over User Datagram Protocol”. This is not a correct statement > and SRTP does in fact violate both of the guidelines mentioned > above: > > - The AAD is not at all limited. In RTP, the associated data consists > of the RTP header, which is not limited as e.g. the header in the TLS > record layer. The RTP header is extensible with proprietary header > extensions carrying any type of information. In RTCP, the scope of > the AAD depends on the encryption flag E. If the encryption flag is > '1', the AAD data is limited to necessary header information, but if > the encryption flag is '0', the AAD consists of the entire RTCP > packet. > > - RTCP receiver reports provide a wealth of information that can be > used to determine the integrity of individual forged RTP packages, > e.g. SSRC of the source, cumulative number of packets lost, extended > highest sequence number received, last SR timestamp, and delay since > last SR. The RTCP extension for port mapping [RFC6284] is even worse > as it echoes back the 64-bit nonce received in the request. > > - RTP Rapid Synchronisation [RFC6051] is used, a forged Rapid > Resynchronisation Request results in a RTP header extension with sync > information sent from the sender. > > - If the RTP header extension Client-to-Mixer Audio Level Indication > [RFC6464] is used, a forged RTP packet with a high audio level will > result in the MCU forwarding the SSRC. As the SSRC is not encrypted, > this is easily detected by the attacker. > > Even if encryption of RTCP is mandated and specific RTP header > extensions and RTCP packets types are forbidden, an attacker may > still in many cases determine whether a forgery was successful by > looking at the length of packets. Either by looking at the length of > RTCP packets from the sender or by looking at the length of RTP > packets forwarded by an MCU. > > A further problem with SRTP and GCM is that SRTP is very often used > in one-to-many scenarios. The maximum number of invocations of each > instance of the authenticated decryption function would have to be > restricted to q/r, where q is the maximum total number of invocations > of the authenticated decryption function, and r is the total number > of receivers, including any late joiners. > > All in all, SRTP does absolutely not meet the NIST guidelines for > usage of GCM with short tags. > > Cheers, John > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 Igoe, Kevin M.
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 Magnus Westerlund
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 Ben Campbell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 Igoe, Kevin M.
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 Ben Campbell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 John Mattsson
- [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15: Iss… Magnus Westerlund
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Stephen Farrell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Ben Campbell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Stephen Farrell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Ben Campbell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Stephen Farrell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Ben Campbell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Stephen Farrell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Ben Campbell