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

John Mattsson <> Tue, 20 May 2014 21:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 123301A083E for <>; Tue, 20 May 2014 14:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1PMPNIPkOLY1 for <>; Tue, 20 May 2014 14:56:33 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94F381A086A for <>; Tue, 20 May 2014 14:55:26 -0700 (PDT)
X-AuditID: c1b4fb25-f79226d000004024-83-537bcf4c102d
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 53.64.16420.C4FCB735; Tue, 20 May 2014 23:55:24 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Tue, 20 May 2014 23:55:23 +0200
From: John Mattsson <>
To: Magnus Westerlund <>, Florian Zeitz <>, "" <>
Thread-Topic: [AVTCORE] Criticism on draft-ietf-avtcore-srtp-aes-gcm
Date: Tue, 20 May 2014 21:55:23 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGfG3RtfnfHWwwcI90hYve1ayW9ybP5/V gcljQm8ro8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKe3KwuOGdXsb+tk72BscG2i5GTQ0LAROL2 gYssELaYxIV769lAbCGBo4wSb2+qdDFyAdlLGCU+vOwCS7AJGEjM3dMAZosI1EvsX3eBCcQW FnCWuNWygR0i7iLx7OAbFgjbTWLioW6wehYBVYknpx6D1fMKmEtM/nKWEWLBVEaJd/dnMYIk OAV0JOZ+gRjKCHTR91NrwGxmAXGJW0/mM0FcKiCxZM95ZghbVOLl43+sILaogJ7Eu+MwNUoS jUueAMU5gHo1Jdbv0ocYYy3x4MExdghbUWJK90N2iHsEJU7OfMIygVF8FpJtsxC6ZyHpnoWk exaS7gWMrKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAmPt4JbfqjsYL79xPMQowMGoxMOr MKM6WIg1say4MvcQozQHi5I470UNoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGuKhG3elb 9bdMmfbki+mK3qxrv3+XzD1t9Ed64na2mwqaPRGLlJ5dMJk3g+s8w0P7ha2rjcRcC6fcdb16 NE1fKfhPuqRnWMLptISQcPubM65YzLxQOWOR/JyX580OBbquTtiX0FF3xXXaj/ufnnjKXV/x W+FSoZjH2tfu0zfrFTualLLo9izyV2Ipzkg01GIuKk4EABs0hpyWAgAA
Subject: Re: [AVTCORE] Criticism on draft-ietf-avtcore-srtp-aes-gcm
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 May 2014 21:56:36 -0000

A second opinion.

My view is that the current version of the draft makes good choices
regarding mandatory-to-implement (16 byte tags), optional-to-implement (8
and 12 bytes tags), and not specified (4 byte GCM tags).

And while older versions of the draft did not, the current version clearly
expresses the constraints that apply to GCM. As with ANY cryptographic
algorithm, developers need to read the specification carefully and follow
all the constraints and requirements given.

While GCM might not handle short tags as “expected”, it actually has
proven security levels where other algorithms have just “expected”
security levels.

GCM's combination of proven security with outstanding performance on
modern processors makes it a welcome addition to SRTP and other security




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

Ericsson AB
Security Research
Färögatan 6
SE-164 80 Stockholm, Sweden
Phone +46 10 71 43 501
SMS/MMS +46 76 11 53 501

On 25/04/14 08:44, "Magnus Westerlund" <>

>Hi Florian and WG,
>Please see inline.
>On 2014-04-25 01:21, Florian Zeitz wrote:
>> On 24.04.2014 16:51, Magnus Westerlund wrote:
>>> Florian,
>> Hello Magnus,
>>> I would like to point out one factual error in your criticism:
>>> The draft does mandate support for the longest 128 bit authentication
>>> tag if one support the cipher at all. This is a quote from Section
>>>    Any implementation of AES-GCM SRTP MUST support both
>>>    and AEAD_AES_256_GCM (the versions with 16 octet AEAD authentication
>>>    tags), and it MAY support the four other variants shown in table 1.
>>> Similarly from 13.2 for AES-CCM
>>>    Any implementation of AES-CCM SRTP/SRTCP MUST support both
>>>    AEAD_AES_128_CCM and AEAD_AES_256_CCM (the versions with 16 octet
>>>    AEAD authentication tags), and MAY support the other four variants.
>>> But, to be fair this was changed very recently.
>> I'm admittedly a bit irritated, by you calling this my criticism.
>> Particularly after having pointed out I do not fully agree with it, but
>> am merely the messenger.
>Sorry, poorly worded to attribute it to you.
>> The parenthetical you refer to is my own analysis however. And in fact
>> it does appear I accidentally read the -10 version of the draft. I do
>> apologize for that mistake.
>>> I would also note that the draft's security consideration section do
>>> discuss the shorter than authentication tag length of actual
>>> authentication protection for AES-GCM.
>>> It is up to the WG to discuss if it thinks there should be any changes
>>> based on your input. And I have to ask you what you think should be the
>>> action based on your personal opinion.
>> I suspect you might be wondering why I'm bringing this up if I don't
>> fully agree with the criticism. The reason is quite simply that I still
>> believe in the IETF culture. In particular I believe that, unlike what
>> many media outlets are claiming recently, the IETF and its WGs are fully
>> capable of appropriately dealing with criticism, and not letting
>> themselves gag by any government agency. (I.e. in some way I'm trying to
>> prove a point here)
>> However, dealing with criticism is only possible, when it is actually
>> expressed towards the WG, which apparently neither Erich Möchel nor
>> Michael Kafka found necessary.
>Thanks for bringing it to the WG's attention. You are correct, that the
>WG needs to be made aware and have the chance to discuss and consider
>> I see two ways to address this:
>> Either the WG agrees with the criticism, the logical consequence of
>> which would be removing GCM from the draft.
>> Or the authors/WG explain why they believe this draft to be reasonably
>> secure, despite the criticism, and proceed with the current wording.
>> David McGrew choose the second option, and I'm personally content with
>> that. Hearing a second opinion from other WG members would be
>> appreciated though.
>I hope the WG participants are happy to review this criticism and
>consider McGrew's response as well as what the current version of the
>draft says in forming their own opinions, and hopefully state where they
>stand. If people have proposals for corrections or clarifications to the
>draft they can also be brought forward.
>>From a process point of view, as this document is currently in a
>publication has been requested state we can continue the WG discussion
>while the AD performs her review. The WG will have to form some
>concluding position at the end of the IETF review if not before.
>I would hope that people can provide their input into this over the next
>two weeks, i.e. by the 9th of May.
>Magnus Westerlund
>As WG chair
>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:
>Audio/Video Transport Core Maintenance