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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 2 Jun 2015 15:42:16 +0200

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
>

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 07 Jun 2015 21:03:07 +0100

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.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 16 Jun 2015 17:12:23 -0500

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:

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Jun 2015 17:33:18 +0100

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.