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

[Stephen Farrell <[e-mail]>]

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

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

Cheers,
S.

> 
> I like to ask you about your characterization of this as being 10 ways
> of using the same algorithm. To my understanding what we have are really
> two different algorithm usages, the AES-GCM and the AES-CCM.
> They appear to have potentially significant differences in how they
> work. Thus having potentially different vulnerabilities. Thus, if we are
> going to have a discussion about how to trim the permutational tree for
> this, I think it is important that we consider this as being a selection
> in three dimensions, namely algorithm, key-length and authentication tag
> length.
> 
> When it comes to the algorithms, this will be the second and third use
> of AES in SRTP, as we already have four operation points using longer
> than 128 bit-keys for SRTP where AES Counter mode is combined with HMAC.
> 
> From Section 5 of RFC 6188.
> 
>                   +-------------------------+-----------+
>                   | Crypto Suite Name       | Reference |
>                   +-------------------------+-----------+
>                   | AES_192_CM_HMAC_SHA1_80 | [RFC6188] |
>                   | AES_192_CM_HMAC_SHA1_32 | [RFC6188] |
>                   | AES_256_CM_HMAC_SHA1_80 | [RFC6188] |
>                   | AES_256_CM_HMAC_SHA1_32 | [RFC6188] |
>                   +-------------------------+-----------+
> 
> Thus lets start with the differences between AES-GCM and AES-CCM. I
> can't argue around there differences. But, I do like to note that I
> personally are fine with treating them as two separate entities. Neither
> are mandatory to implement in an SRTP implementation. We have today only
> one MTI encryption algorithm namely AES-CM with 128 keys and 80-bit
> SHA-1 HMAC. This document change none of that, and the consideration for
> SRTP not mandatory (RFC 7202) applies here. These algorithm will have to
> be mandated by other specifications until that point that someone see a
> need to update the MTI in RFC 3711.
> 
> Thus, the document provides two choices, where you can select to use
> only one of them. And if you select either they have their MTI
> configuration, thus ensuring that any implementation have at least one
> common configuration per algorithm.
> 
> Thus lets look at the configurations on a per algorithm basis:
> 
> AES-GCM:
> 
>          AEAD_AES_128_GCM    = {TBD, TBD }
>          AEAD_AES_256_GCM    = {TBD, TBD }
>          AEAD_AES_128_GCM_12 = {TBD, TBD }
>          AEAD_AES_256_GCM_12 = {TBD, TBD }
> 
> 
> This is four alternatives, with either 128 or 256 bit keys and the
> choice between 12 and 16 bytes authentication tag.
> 
> AES-CCM
>          AEAD_AES_128_CCM    = {TBD, TBD }
>          AEAD_AES_256_CCM    = {TBD, TBD }
>          AEAD_AES_128_CCM_8  = {TBD, TBD }
>          AEAD_AES_256_CCM_8  = {TBD, TBD }
>          AEAD_AES_128_CCM_12 = {TBD, TBD }
>          AEAD_AES_256_CCM_12 = {TBD, TBD }
> 
> AES-CCM has the choices between the 128 and 256 bit keys with
> authentication tags with a length of 8, 12 or 16 bytes.
> 
> From my perspective, I don't see many obvious candidates to remove. I
> think the AES-CCM 12 bytes tags could go. You either care about
> tag-length and then that is so important that you accept the weakness of
> the 8 byte ones, or you can use 16 bytes to get the stronger protection.
> The half-way point seems a bit unnecessary. This is based on that there
> are cases where people either care about the authentication overhead or
> they don't thus, having a weaker shorter and a long strong one appears
> reasonably motivated, as long as the short isn't so weak that it will be
> highly susceptible to forging.
> 
> Thus, I think the main question remaining if one tries to reduce this
> further, is 128 bit keys to short in today's world for actual
> standardization?
> 
> I don't know the answer, nor have an opinion on it.
> 
> Cheers
> 
> Magnus Westerlund
> 
> 
> On 2015-02-06 16:05, Stephen Farrell wrote:
>>
>> Hi Magnus,
>>
>> I had hoped the WG would chime in but apparently they do not
>> care much about this topic.
>>
>> I'd take that as indicating that it is ok to remove some of
>> the options since nobody is yelling that they are all needed.
>>
>> After all - is there really a need to define 10 ways of using
>> one algorithm (AES) to do pretty much exactly the same thing?
>>
>> I think 10 options is just damaging to interop even if done for
>> the best of motives.
>>
>> S.
>>
>> On 29/01/15 11:02, Magnus Westerlund wrote:
>>> Hi Stephen, All,
>>>
>>> (Adding the AVTCORE WG): WG there are feedback requested from you below!
>>>
>>> I am taking over as shepherd for this document and would like to make
>>> some progress here.
>>>
>>> I would like to make some observations around the discuss.
>>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ballot/#stephen-farrell
>>>
>>> First, that Stephen appear to grouping AES-GCM and AES-CCM into one
>>> bucket. From my perspective they are defined as two different ciphers
>>> for SRTP but within a single document. One can implement either of them
>>> without any requirement on implementing the other from this document.
>>>
>>> Each of them have MTI requirements on configurations that MUST be
>>> supported if one support that particular cipher. That is defined as
>>> strongest for each key length.
>>>
>>> >From the draft:
>>>
>>> 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.
>>>
>>> Section 13.2:
>>>
>>>    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.
>>>
>>> I would further also note that to make anything MTI for SRTP independent
>>> on deployment and usage, then a document must Update the MTI definition
>>> in RFC 3711, something that hasn't been done yet. So far it is up to the
>>> umbrella specifications, like WebRTC etc as discussed in SRTP not
>>> mandatory document (RFC 7202) to define what ciphers that MUST be
>>> implemented. And if we are updating RFC 3711 the mandatory to implement
>>> for any SRTP implementation will certainly be a question.
>>>
>>>
>>> When it comes to the core of your discuss if these 4 (AES-GCM) + 6
>>> (AES-CCM) options must be defined. That is difficult question. One which
>>> is difficult to answer within the context of the WG actually. As David
>>> has raised in the private discussion so far there will be people that
>>> will argue anything other than the longest tags and keys are acceptable,
>>> others will note that using the 16 byte authentication tags do results
>>> in the authentication data being more than the RTP payload (single audio
>>> frame) for a number of the audio formats we have. Me personally I think
>>> I would remove the 12 bytes tag-length from AES-CCM to reduce the number
>>> of options. But two tag-lengths and two key-lengths do not appear
>>> excessive.
>>>
>>> WG, the chairs and ADs appreciate feedback on your view here.
>>>
>>>
>>> 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]
>>> ----------------------------------------------------------------------
>>>
>>
>>
> 
>