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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 22 July 2015 11:25 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 2D6271ACE6D for <avt@ietfa.amsl.com>; Wed, 22 Jul 2015 04:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRHSnDqUjhdN for <avt@ietfa.amsl.com>; Wed, 22 Jul 2015 04:25:22 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EC61B2BFB for <avt@ietf.org>; Wed, 22 Jul 2015 04:25:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 074B6BDCF; Wed, 22 Jul 2015 12:25:07 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTldzDNZDsPz; Wed, 22 Jul 2015 12:25:04 +0100 (IST)
Received: from [31.133.179.222] (dhcp-b3de.meeting.ietf.org [31.133.179.222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 89C17BE58; Wed, 22 Jul 2015 12:25:03 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437564303; bh=cAQ/5Xr0zxRCQYH6XHGNrojnKn3C0qzdT53+diCreFU=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=XkAm5VOUhAyW64RrwkbiUBK5ULFOkgOQ+w7zhHq0RDfxeeAw83FvYp+oM2TcFVRo0 ZUmH84DDnRa5ZuuAlB20dZPJKcCU4sSoE1ZfiDTtqokCzQcuxJOHxxKIC3C21i+6zN Wojxu8YoUYQl7NsLUU5/v136OxclRF2LaUfaK9iI=
Message-ID: <55AF7D8E.6080905@cs.tcd.ie>
Date: Wed, 22 Jul 2015 12:25:02 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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 <ben@nostrum.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> <556DB2B8.6060307@ericsson.com> <5574A37B.9050609@cs.tcd.ie> <C5850A6F-0346-47A7-858A-85045AFEAD45@nostrum.com> <5591734E.4060805@cs.tcd.ie> <D75DDFFC-5A07-4EA2-A081-7D5E0DB85ABF@nostrum.com> <55AF7CE0.3080400@cs.tcd.ie> <AEF2339A-7953-45BF-A8F4-1046B8A8E1EE@nostrum.com>
In-Reply-To: <AEF2339A-7953-45BF-A8F4-1046B8A8E1EE@nostrum.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/lf8S-fZ5K07HYy191nMnYXc3Gn0>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, Tim Polk <tim.polk@nist.gov>, avt@ietf.org, mcgrew@cisco.com
Subject: Re: [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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 22 Jul 2015 11:25:25 -0000


On 22/07/15 12:23, Ben Campbell wrote:
> I think you already cleared, but you had mentioned re-reviewing after
> the short tag was removed :-)

/me forgets stuff:-)

I'm sure it's fine to proceed in that case. I'd not get to it this
week tbh.

S

> 
> On 22 Jul 2015, at 13:22, Stephen Farrell wrote:
> 
>> 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
>> S
>>
>>>
>>> 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.
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Audio/Video Transport Core Maintenance
>>>>>> avt@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/avt