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