Subject: Re: [AVTCORE] draft-ietf-avtcore-srtp-aes-gcm-15: Issue with short tags

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Jul 2015 13:20:27 +0200

Hi Stephen,

It looks like version 17 removed the short tag. Do you still expect to 
re-review?

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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/avt

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Jul 2015 12:22:08 +0100

> It looks like version 17 removed the short tag. Do you still expect to

Nope, will clear soon's I get a chance
S

>>> 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
>>>>> I have seen no reactions on this email from John. To my understanding
>>>>>> standardized by IETF even if the NIST requirements are followed, in
>>>>>> Regarding the general usage of GCM with short tags, I wrote a paper
>>>>>> 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
>>>>>> Note that draft-ietf-avtcore-srtp-aes-gcm-15 does not follow the NIST
>>>>>> requirements, it choses deliberately to ignore them. This means that
>>>>>> 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:
>>>>>> Real-time Transport Protocol carrying Voice over Internet Protocol,
>>>>>> running over User Datagram Protocol”. This is not a correct statement
>>>>>> - 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
>>>>>> 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
>>>>>> - RTCP receiver reports provide a wealth of information that can be
>>>>>> 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
>>>>>> Resynchronisation Request results in a RTP header extension with sync
>>>>>> - 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,
>>>>>> looking at the length of packets. Either by looking at the length of
>>>>>> 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
>>>>>> restricted to q/r, where q is the maximum total number of invocations
>>>>>> of the authenticated decryption function, and r is the total number

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Jul 2015 13:23:41 +0200

I think you already cleared, but you had mentioned re-reviewing after 
the short tag was removed :-)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Jul 2015 12:25:02 +0100

> 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

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 22 Jul 2015 13:26:38 +0200

Thanks. I will approve it as soon as I make sure the process ducks are 
still inline.