Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15

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

------------------------------------------------------------------
John Mattsson
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator 
Senior Researcher, Security

Ericsson AB                             Phone +46 10 71 43 501               
Ericsson Research                       SMS/MMS +46 76 11 53 501
Färögatan 6                             john.mattsson@ericsson.com
SE-164 80 Stockholm, Sweden             www.ericsson.com
------------------------------------------------------------------

> On 16 Apr 2015, at 22:19, Ben Campbell <ben@nostrum.com> wrote:
> 
> Thanks!
> 
> On 16 Apr 2015, at 15:03, Igoe, Kevin M. wrote:
> 
>> Nothing substantive that needs Stephen's attention yet.  He'll probably grump
>> using a  -8 versus a -64 to denote an 8 byte tag sizes, but that decision was made
>> in RFC 5282 long before this ID came along,
>> 
>>> -----Original Message-----
>>> From: Ben Campbell [mailto:ben@nostrum.com]
>>> Sent: Thursday, April 16, 2015 3:48 PM
>>> To: Igoe, Kevin M.
>>> Cc: avt@ietf.org
>>> Subject: Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15
>>> 
>>> Hi,
>>> 
>>> Should Stephen look at this version in regards to his DISCUSS, or do you want to wait for the final one?
>>> 
>>> Thanks!
>>> 
>>> Ben.
>>> 
>>> On 14 Apr 2015, at 9:34, Igoe, Kevin M. wrote:
>>> 
>>>> A new interim draft draft-ietf-avtcore-srtp-aes-gcm-15 has been
>>>> posted.  This has (I hope) expunged any references to AES-GCM and
>>>> reduced to only 3 modes of AES-GCM.  The final draft will include test
>>>> vectors.
>>>> 
>>>> I'm being cautious in the generation of test vectors (with
>>>> intermediate values displayed) becuse , you REALLY don't want any
>>>> typo's or other errors in test vectors.
>>>> 
>>>> _______________________________________________
>>>> Audio/Video Transport Core Maintenance avt@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/avt
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt