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
- [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 Igoe, Kevin M.
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 Magnus Westerlund
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 Ben Campbell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 Igoe, Kevin M.
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 Ben Campbell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15 John Mattsson
- [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15: Iss… Magnus Westerlund
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Stephen Farrell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Ben Campbell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Stephen Farrell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Ben Campbell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Stephen Farrell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Ben Campbell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Stephen Farrell
- Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15:… Ben Campbell