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