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

[Magnus Westerlund <[e-mail]>]

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 13.1:
>>
>>    Any implementation of AES-GCM SRTP MUST support both AEAD_AES_128_GCM
>>    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 this.

> 
> 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.

Regards

Magnus Westerlund
As WG chair

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------