Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS)

[Alissa Cooper <[e-mail]>]

For scheduling purposes I put this on the agenda for the next informal (Feb 26 at 16:30 UTC) and have reached out to the authors separately to see if they are available. If it gets resolved before then we can remove it from the agenda.

Alissa

On Feb 10, 2015, at 5:48 AM, Magnus Westerlund <[e-mail]> wrote:

> Hi,
> 
> I would definitely want the authors to step in now and provide their
> reasoning for why these options have been included.
> 
> 
> 
> On 2015-02-09 23:58, Stephen Farrell wrote:
>> 
>> Hi Magnus,
>> 
>> On 09/02/15 12:05, Magnus Westerlund wrote:
>>> Hi Stephen,
>>> 
>>> (as individual)
>>> I also wished the WG was more active.
>> 
>> Yep, hard to evaluate consensus with so few commenting.
>> 
>> Thanks for the good analysis below, I'll respond here as I think
>> that's better done in reverse order almost.
>> 
>> - aes-128 in any flavour is good enough, there's IMO no pressing
>>  need for aes-256 here
> 
> Despite that we have a definition for AES-256 for SRTP already and
> personally I find it a bit difficult to throw away work for something we
> are likely to going to need in the future.
> 
>> - gcm vs. ccm: those are functionally equivalent as far as this
>>  application is concerned I think - the only reason to have both
>>  is if one has to deal with systems that only support one and not
>>  the other; ccm is all that is available on some very constrained
>>  devices for essentially historical reasons and again I don't see
>>  why that is an issue here (it could be, but I don't recall anyone
>>  saying that it is - apologies if I've forgotten)
> 
> Well, if I understand the security analysis then apparently CCM is less
> sensitive to a weak authentication, and could use the 64 bit
> authentication tag, while GCM needs a stronger one. Thus, from that
> perspective, if we at all are going to have a shorter authentication tag
> then 128 bits, then why not use the 64 bit CCM then as that is
> significant saving, rather than only four bytes for the GCM.
> 
>> - I tend to agree with you about the 192 label
>> 
>> If I were correct in the above then all that'd be really needed is
>> 
>>          AEAD_AES_128_GCM    = {TBD, TBD }
>>          AEAD_AES_128_GCM_12 = {TBD, TBD }
>> 
>> I'd argue that 2 options vs. 10 options may lead to overall
>> better security and interop. as there will be many systems and
>> libraries with less code and hence fewer bugs. (It's credible
>> to argue that code size reduction might outweigh adding aes-256
>> in a case where you don't worry about ciphertext being secure
>> for decades.)
> 
> I understand the desire to avoid proliferation here. I might not see the
> 256 bit keys in the same way. Make it clear that they are optional and
> that anyone supporting AES-GCM MUST support 128-bit keys. But based on
> the above reasoning if we are doing only AES-GCM then I rather see:
> 
>            AEAD_AES_128_GCM    = {TBD, TBD }
>            AEAD_AES_256_GCM    = {TBD, TBD }
> 
> If we based on my above argumentation think we should provide a short
> tag version then I think the set to define would become:
> 
>         AEAD_AES_128_CCM    = {TBD, TBD }
>         AEAD_AES_256_CCM    = {TBD, TBD }
>         AEAD_AES_128_CCM_64 = {TBD, TBD }
>         AEAD_AES_256_CCM_64 = {TBD, TBD }
> 
> Using Martin's suggestion for being consistent in bits vs bytes.
> 
>> 
>> If we continue to have so few folks engaging on this maybe the
>> best way to handle it would be to talk about it on an IESG
>> informal telechat if we can get you and David (and Russ) all
>> on the call? (Or over a beer in Dallas I guess as that's also
>> getting close and there a bunch of IESG calls coming up that
>> are devotes to BoFs and the Dallas schedule.)
>> 
> 
> Yes, unless we get more opinions now, I think the way forward is to go
> that road so that we can conclude.
> 
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> 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]
> ----------------------------------------------------------------------
>