[AVTCORE] Criticism on draft-ietf-avtcore-srtp-aes-gcm

[David McGrew <[e-mail]>]

Hi Florian,

thanks for calling this to the attention of the list.   I had not seen 
it before, and I had not been contacted by Erich Möchel (the author of 
the post you cite) or anyone else in regard to these speculations. The 
post is wrong on many important points; please see more inline:

> From: Florian Zeitz <[e-mail]>
> Subject: [AVTCORE] Criticism on draft-ietf-avtcore-srtp-aes-gcm
> Date: April 22, 2014 at 8:11:17 AM PDT
> To: [e-mail]
>
> Hello,
>
> I'd like to call this working group's attention to the fact that 
> yesterday an article in german language[1] was published, harshly 
> criticising draft-ietf-avtcore-srtp-aes-gcm-11.
>
> The draft is therein called the NSA's newest attempt at weakening 
> internet security. The criticism is largely based on Niels Ferguson's 
> 2005 paper "Authentication weaknesses in GCM"[2].
>

Ferguson's critique refers to the initial submission to NIST on GCM; 
please note that the submission was later revised and clarified. For 
background, see the comments on that work in Section 2 of the "GCM 
update" that was submitted to NIST along with the revised version of 
that specification back in 2005, which are online at 
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/gcm-update.pdf 
The reference on multiple-forgery attacks, which is cited in the NIST 
submission, is online at https://eprint.iacr.org/2005/161.pdf Also, the 
NIST specification of GCM, which is the authoritative one, includes 
guidance on tag lengths that was absent from the version of the 
specification to which the critique refers.

> In particular the points I can identify are:
>
> Repeated from Ferguson's paper
> * GCM should no longer be used
> * if GCM has to be used, the authentication tag should be 128-bit (the 
> draft currently mandates implementation of the 64-bit variant, the 
> others are purely optional)

The statement on tag lengths is wrong, as Magnus recently pointed out on 
the list.  Earlier versions of the draft had 64-bit tags as mandatory to 
implement and 128-bit tags as optional, but the current version reverses 
that.  We made this change after discussion between the authors, 
reviewers and the chairs.   In more detail: on 11/03, John Mattsson 
reviewed draft-ietf-avtcore-srtp-aes-gcm, and provided comments to 
Magnus Westerlund, Richard Barnes, Kevin Igoe, and myself.   John and 
Kevin decided that the mandatory-to-implement GCM tag size should be 
changed to 128 bits.  (John, Magnus, Richard and Kevin, please check for 
Kevin's email on this subject dated 2/19/14).

Of course, this is a working group draft and should reflect the 
consensus of AVTCORE.  But it currently has strong 
mandatory-to-implement options and good guidance on parameter choices, 
as noted below.

> * the paper uses telephony as an example in it's "A disastrous scenario"
> section. Yet this draft recommends GCM for telephony
>
> Attributed to Michael Kafka, a "security expert" from Vienna:
> * mixing confidentiality and authentication makes attacks easier

This statement is wrong.  Authenticated encryption as provided by 
dedicated algorithms like GCM is widely regarded as better than loosely 
bound authentication and encryption.   To appreciate why a loose binding 
between authentication and encryption is a bad idea, see for instance 
the padding oracle attacks against CBC in TLS and other protocols, which 
are possible because of the loose binding, as first described by 
Vaudenay and developed in BEAST and Lucky-13.

> * in practice performance gains are negligible on modern smartphones
>
> The article also insinuates that David McGrew is deliberately 
> co-authoring a draft he knows to be insecure, somehow under the 
> pressure of the NSA.

This is also not true.  I'm not under any pressure from the NSA, and the 
draft provides an adequate level of security.  Importantly, the draft 
very explicitly describes the authentication strength that one can 
expect from a given choice of tag length, in Section 14.2
http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-11#section-14.2 
It would be disingenuous to suggest that the draft has some sort of 
hidden weakness regarding authentication strength, as the draft is very 
clear about the authentication strength one can expect for different 
parameter choices.

For perspective, one should also consider the authentication strength of 
some existing standards.  SDP Security Descriptions (RFC 4568) includes 
the option of a 32-bit authentication tag 
http://tools.ietf.org/html/rfc4568#section-6.2.2 And Secure RTP itself 
(RFC 3711) allows encryption with *no* authentication. The rationale for 
this is outlined in Section 7.5 of that RFC, and Section 9.5.1 outlines 
the security considerations of weak or NULL authentication in SRTP.  
Just to be clear: the standards cited above provide much less 
authentication strength than the weakest option in 
draft-ietf-avtcore-srtp-aes-gcm.

For more perspective, let's go through an example based on the table in 
the section of the GCM and CCM draft.  Consider an scenario in which a 
receiver in an audio session with a typical rate of 50 packets per 
second receives a steady stream of forged messages for an entire day, 
which are protected by 64-bit GCM authentication tags.  If the receiver 
is patient enough to listen to an entire day's worth of silence (due to 
the fact that SRTP will discard forged packets), the attacker will have 
a one in a billion probability of successfully forging
a message.  Many people would be OK with this level of risk.  Others 
would not, in which case they should use a larger GCM tag size, which 
they could choose from the table.  Or they could use CCM, which is also 
described in the draft, or SRTP with HMAC authentication. Please also 
note that the table in the draft takes the conservative approach of 
assuming that packets are large (and thus per-packet authentication is 
slightly weaker).

I personally favor the use of large authentication tags, both in SRTP 
and for GCM, but I grudgingly concede that short tags are adequate for 
some scenarios where bandwidth matters a lot. When SRTP was developed 
and standardized, around 2003, it was necessary to allow weak 
authentication options because of bandwidth constraints faced by some 
RTP users.   To put it plainly: some RTP users at the time said that 
they would not use SRTP if it required long authentication tags.   The 
discussions on this tradeoff took place within AVT and are well 
documented.   In any case, it is reasonable to debate whether or not 
short authentication tags are ever appropriate, but it would be wrong to 
claim that any version of draft-ietf-avtcore-srtp-aes-gcm described 
authentication options that are weaker than those already present in the 
SRTP standard.

This is somewhat off topic, but I did participate in some recent work 
that aims to provide better security within limited bandwidth, which was 
submitted to the IETF last year and presented at the last IRTF CFRG 
meeting: "Authenticated Encryption with Replay prOtection (AERO)" 
http://tools.ietf.org/html/draft-mcgrew-aero-01 and "Using Authenticated 
Encryption with Replay prOtection (AERO) in SRTP" 
http://tools.ietf.org/html/draft-mcgrew-srtp-aero-01.  Some more 
research needs to be done to refine and validate this approach, but it 
appears promising as a future direction (in scenarios in which the 
endpoints can afford some additional computation during encryption).

>
> While I do not necessarily personally agree with the criticism, or the 
> conclusions, I would like this working group and the authors to 
> address it in some way.
>

Thank you for calling this to the attention of the list, and thus giving 
me the opportunity to respond to the posting that you referenced.

regards,

David