Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15: Issue with short tags
"Ben Campbell" <ben@nostrum.com> Wed, 22 July 2015 11:27 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 576D01ACE6D for <avt@ietfa.amsl.com>; Wed, 22 Jul 2015 04:27:00 -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 OevnVBqmoOUd for <avt@ietfa.amsl.com>; Wed, 22 Jul 2015 04:26:57 -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 59E911B2BE4 for <avt@ietf.org>; Wed, 22 Jul 2015 04:26:55 -0700 (PDT)
Received: from [31.133.176.150] (dhcp-b096.meeting.ietf.org [31.133.176.150]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6MBQiTr040300 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jul 2015 06:26:46 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host dhcp-b096.meeting.ietf.org [31.133.176.150] claimed to be [31.133.176.150]
From: Ben Campbell <ben@nostrum.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Wed, 22 Jul 2015 13:26:38 +0200
Message-ID: <84FE7EBF-26AE-4E55-8FBC-8E711E652D3E@nostrum.com>
In-Reply-To: <55AF7D8E.6080905@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> <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> <55AF7D8E.6080905@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.2r5107)
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/kYzk89tQX9hiTGzZwyQ8xNIGKEQ>
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:27:00 -0000
Thanks. I will approve it as soon as I make sure the process ducks are still inline. On 22 Jul 2015, at 13:25, Stephen Farrell wrote: > 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
- [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