Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15: Issue with short tags

"Ben Campbell" <> Tue, 16 June 2015 22:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3630B1AC43A for <>; Tue, 16 Jun 2015 15:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zp27m5zj3ps0 for <>; Tue, 16 Jun 2015 15:12:41 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0E2D61AC42A for <>; Tue, 16 Jun 2015 15:12:41 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.15.1/8.14.9) with ESMTPSA id t5GMCNJA046290 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 16 Jun 2015 17:12:26 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
To: Stephen Farrell <>
Date: Tue, 16 Jun 2015 17:12:23 -0500
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <>
Cc: Magnus Westerlund <>, Tim Polk <>, "" <>, "" <>
Subject: Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15: Issue with short tags
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Jun 2015 22:12:44 -0000

Hi Stephen,

If you are satisfied, please feel free to clear, unless you want to hold 
a discuss on the short tag issue itself. I will not approve until that 
(and some other things) are resolved.


On 7 Jun 2015, at 15:03, Stephen Farrell wrote:

> Hi all,
> I currently have a discuss on this for a related reason that
> would otherwise be cleared by -16. I also support removal of the
> ciphersuite discussed below.
> So for Ben and chairs - I can either clear or keep my discuss
> and am happy to do whichever you prefer - just let me know.
> Lastly - thanks all for your forbearance in putting up with me
> trying to trim the list of ciphersuites at the last stage in
> the process.
> Cheers,
> S.
> On 02/06/15 14:42, Magnus Westerlund wrote:
>> 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.
>>> 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
> _______________________________________________
> Audio/Video Transport Core Maintenance