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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 07 June 2015 20:03 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 2644B1ACD70 for <avt@ietfa.amsl.com>; Sun, 7 Jun 2015 13:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 i-6_kB8zadRn for <avt@ietfa.amsl.com>; Sun, 7 Jun 2015 13:03:16 -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 150141ACD74 for <avt@ietf.org>; Sun, 7 Jun 2015 13:03:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0082CBE5C; Sun, 7 Jun 2015 21:03:09 +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 T5aooZBi1bP3; Sun, 7 Jun 2015 21:03:08 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.23.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DBEEDBE53; Sun, 7 Jun 2015 21:03:07 +0100 (IST)
Message-ID: <5574A37B.9050609@cs.tcd.ie>
Date: Sun, 07 Jun 2015 21:03:07 +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.7.0
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, 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> <556DB2B8.6060307@ericsson.com>
In-Reply-To: <556DB2B8.6060307@ericsson.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/VZJ-EC2_gVQAfN5Dos5K61DiG4k>
Cc: Tim Polk <tim.polk@nist.gov>
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: Sun, 07 Jun 2015 20:03:19 -0000

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
>>
> 
>