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

[John Mattsson <[e-mail]>]

My view is that we should standardize GCM and CCM as well as both 128-bit and 256-bit keys, but not necessarily all combinations. Having the option of 64-bit tags also makes a lot of sense. 10 protection profiles are a bit much.  If I were to choose a bare minimum set of needed protection profiles, my choice would be:
 AEAD_AES_128_CCM_64
 AEAD_AES_128_GCM_96
 AEAD_AES_256_GCM
Regarding 256-bit keys, there are such requirements for national security. I definitely think we should have a 256-bit option (and currently there are no such protection profile). I think users of 256-bit keys would like 128-bit tags and GCM.
Regarding CCM, it is currently used mostly in constrained devices where it is a better fit that GCM. CCM_64 is currently the default TLS cipher suite for COAP. I think we should have an SRTP option for these devices and then CCM_64 makes sense.
Regarding tag lengths, I don’t see the practical security need for long tag lengths, long authentication tags is less important in SRTP than in TLS or IPsec. Even 64-bit tags offer very good protection as an attacker would need to send 2^64 randomly forged messages before a single one (with a random plaintext) would be validated. Receiving 2^64 packages is far more serious then accepting 20 ms of random noise. I think 96-bit authentication tags make sense for most users of AES_128_GCM.
(BTW, SRTP has only 4 registered protection profiles. TLS has 327 registered cipher suites! Why is IESG suddenly reacting when SRTP is getting some well-needed AEAD algorithms? ;)
John

On 10 Feb 2015, at 21:21, Alissa Cooper <[e-mail]<mailto:[e-mail]>> wrote:

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]<mailto:[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]<mailto:[e-mail]>
----------------------------------------------------------------------


_______________________________________________
Audio/Video Transport Core Maintenance
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/avt