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

[Magnus Westerlund <[e-mail]>]

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