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

Stephen Farrell <> Wed, 22 July 2015 11:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 50C611B2A8A for <>; Wed, 22 Jul 2015 04:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F23UinFEoJ4U for <>; Wed, 22 Jul 2015 04:22:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC3781B2A68 for <>; Wed, 22 Jul 2015 04:22:12 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59CE9BE73; Wed, 22 Jul 2015 12:22:11 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2-hDqmrDzAqP; Wed, 22 Jul 2015 12:22:09 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 2186FBDF9; Wed, 22 Jul 2015 12:22:09 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1437564129; bh=C+ry2mi5VlAnITwlIg6OIacMDq0im3pTjTWedlC+PsU=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=2N+SDYJmlQ2fyiyt39fHGb0nQMigr6FJtUVb3cQCkKArXFC+bMcTUrmKkeREtm6sT ZYKJDGnIxZP8lMJvvwOz1HEHgOxIir4bd9/5Cv8AH9RKRrYcIS0RIw927z4be+C9dI 02yL1tLAjWKUeK/C7shBGvuS3ieQDJTb0Hy3fi7A=
Message-ID: <>
Date: Wed, 22 Jul 2015 12:22:08 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: Ben Campbell <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
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: Wed, 22 Jul 2015 11:22:15 -0000

On 22/07/15 12:20, Ben Campbell wrote:
> Hi Stephen,
> It looks like version 17 removed the short tag. Do you still expect to
> re-review?

Nope, will clear soon's I get a chance

> Thanks!
> Ben.
> On 29 Jun 2015, at 18:33, Stephen Farrell wrote:
>> Hi Ben,
>> Back from vacation... and I've cleared that. Happy to review
>> when the short tag stuff is taken out of course (and I support
>> taking that out).
>> Cheers,
>> S.
>> On 16/06/15 23:12, Ben Campbell wrote:
>>> 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.
>>> Thanks!
>>> Ben.
>>> 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