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

"Ben Campbell" <ben@nostrum.com> Tue, 16 June 2015 22:12 UTC

Return-Path: <ben@nostrum.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 3630B1AC43A for <avt@ietfa.amsl.com>; Tue, 16 Jun 2015 15:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zp27m5zj3ps0 for <avt@ietfa.amsl.com>; Tue, 16 Jun 2015 15:12:41 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2D61AC42A for <avt@ietf.org>; Tue, 16 Jun 2015 15:12:41 -0700 (PDT)
Received: from [10.10.1.4] ([162.216.46.97]) (authenticated bits=0) by nostrum.com (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 ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.97] claimed to be [10.10.1.4]
From: "Ben Campbell" <ben@nostrum.com>
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Date: Tue, 16 Jun 2015 17:12:23 -0500
Message-ID: <C5850A6F-0346-47A7-858A-85045AFEAD45@nostrum.com>
In-Reply-To: <5574A37B.9050609@cs.tcd.ie>
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>
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: <http://mailarchive.ietf.org/arch/msg/avt/TDyiSkdbPBYQG0_zUS3S0datfEY>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, Tim Polk <tim.polk@nist.gov>, "avt@ietf.org" <avt@ietf.org>, "mcgrew@cisco.com" <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: <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, 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.

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