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

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Feb 2015 15:05:36 +0000

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  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 9 Feb 2015 13:05:43 +0100

Hi Stephen,

(as individual)
I also wished the WG was more active.

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

-- 

Magnus Westerlund

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Feb 2015 22:58:34 +0000

Hi Magnus,

> 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

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.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Feb 2015 10:38:58 +1100

>           AEAD_AES_128_GCM_12 = {TBD, TBD }

FWIW, I agree with Stephen here.  Other than knowing of its existence,
I haven't been following this work at all.  But I really don't want
SRTP cipher suite proliferation.

I'm personally uninterested in a suite with an abbreviated tag, given
that it's a mere 4 octets of savings.  I know that this was a big deal
in the past, but that gave us the _24 (bits) variants.  In this case,
either save bits by being more aggressive, or drop the _12 (bytes)
variant.

If you keep it, please be consistent and call it _96.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Feb 2015 14:48:53 +0100

Hi,

I would definitely want the authors to step in now and provide their
reasoning for why these options have been included.

> - aes-128 in any flavour is good enough, there's IMO no pressing

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.

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

> in a case where you don't worry about ciphertext being secure

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:

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.

> 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

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 10 Feb 2015 12:21:01 -0800

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

---

From: John Mattsson <[email-masked]>
Date: Wed, 11 Feb 2015 13:35:39 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Alissa

On Feb 10, 2015, at 5:48 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Hi Magnus,

(as individual)

Cheers

Magnus Westerlund

SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>

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

---

From: David McGrew <[email-masked]>
Date: Sun, 15 Feb 2015 09:09:17 -0500

Hi Magnus,

> reasoning for why these options have been included.

because it has been conventional practice for crypto standards to provide a variety of security levels and a diversity of crypto mechanisms.   Certainly this has been the case historically, and eight of the ten ciphersuites have been in the draft ever since October 27, 2008, when draft-mcgrew-srtp-aes-gcm-01 was first submitted.  There was not any feedback that eight or ten was excessive until Stephen raised his Discuss issue.  

My opinion is: it would be best to preserve the existing specification and implementation work, and retain all ten crypto suite definitions.   But if we want to make SRTP-AEAD be the first instance in which the IETF will  prioritize simplicity over variety and diversity, I’m good with that, because I certainly see the value of simplicity; then my recommendation would be to eliminate the four 12-octet authentication versions.  That would leave just six crypto suites, with two different modes of operation, two different key sizes, and two different tag lengths (but not all tag lengths for all modes), like this:

      srtp-crypto-suite-ext = "AEAD_AES_128_GCM"    /
                              "AEAD_AES_256_GCM"    /
                              "AEAD_AES_128_CCM"    /
                              "AEAD_AES_256_CCM"    /
                              "AEAD_AES_128_CCM_8"  /
                              "AEAD_AES_256_CCM_8"  /

Please see more inline.

> are likely to going to need in the future.

Agreed.

>>  saying that it is - apologies if I've forgotten)

Some other considerations:

- CCM performs well on platforms that have AES acceleration, and it may outperform GCM on those systems, if they don’t have a good way to do the multiply-and-accumulate for GCM

- including both CCM and GCM allows for diversity of crypto mechanism and implementation.  

> significant saving, rather than only four bytes for the GCM.

Exactly.   CCM has more robust authentication at shorter tag sizes.   Many people (including John Mattson on this thread) point out that GCM with 64-bit tags provides adequate security in realistic scenarios.   However, it is desirable to include CCM regardless, because CCM is quantifiably better (I believe it has the strongest authentication of any real world AEAD mode, actually) and because of the possibility that 1) someone in the future will come up with an actual SRTP scenario in which 64-bit authentication for GCM is inadequate, or 2) someone will come up with a contrived scenario in which GCM authentication looks inadequate.   #2 may be more likely than #1, but in any case, we should produce a standard that is future proof against either scenario.

I hope that this makes sense.   I regret that I do not have a lot of time to devote to these issues at present; my main contributions to this draft are several years old at this point.

best,

David

> that road so that we can conclude.

David McGrew, PhD
Cisco Fellow
Office of the CTO, Security Business Group, Cisco Systems

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Feb 2015 17:01:41 +0100

On 2015-02-15 15:09, David McGrew wrote:
> 
> My opinion is: it would be best to preserve the existing specification
> and implementation work, and retain all ten crypto suite definitions.  
> But if we want to make SRTP-AEAD be the first instance in which the IETF
> will  prioritize simplicity over variety and diversity, I’m good with
> that, because I certainly see the value of simplicity; then my
> recommendation would be to eliminate the four 12-octet authentication
> versions.  That would leave just six crypto suites, with two different
> modes of operation, two different key sizes, and two different tag
> lengths (but not all tag lengths for all modes), like this:
> 

Stephen, WG

Having looked at the feedback provided in this discussion so far, I
think the above set of 6 are a reasonable selection without unduly
limiting functionality, but removing the four least necessary profiles.

My proposal is that if no one is disagreeing with this in the next week
(Prior to Feb 26 at 16:30 UTC) we use it. If someone disagrees we hold a
discussion at the informal IESG telechat on how to proceed.

Cheers

Magnus Westerlund

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Mon, 23 Feb 2015 12:16:03 +0000

I am content with that.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, February 19, 2015 11:02 AM
> To: David McGrew
> Cc: Stephen Farrell; [email-masked]; [email-masked]; The IESG; Igoe, Kevin M.; IETF
> AVTCore WG
> Subject: Re: Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS)
> 
> > But if we want to make SRTP-AEAD be the first instance in which the
> > IETF will  prioritize simplicity over variety and diversity, I'm good
> > with that, because I certainly see the value of simplicity; then my
> Having looked at the feedback provided in this discussion so far, I think the above set of 6 are a reasonable selection without unduly
> My proposal is that if no one is disagreeing with this in the next week (Prior to Feb 26 at 16:30 UTC) we use it. If someone disagrees we
> hold a discussion at the informal IESG telechat on how to proceed.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 23 Feb 2015 23:16:39 +0000

I am fine with keeping only these 6 suites by eliminating 96 bit auth tags.

However, I do wonder if any SRTP application will ever use CCM with full
length tags or 256 bit keys, rather than using GCM. If not, another 3
suites can be eliminated, leaving only 3 suites:

AEAD_AES_256_GCM
AEAD_AES_128_GCM
AEAD_AES_128_CCM_8/64

I also agree with John that 64 bit auth tags are sufficient for SRTP even
using GCM. The NIST recommendation is key rotation after roughly 2^40
packets of 1.5 KB, which is many years for a 100 Mbps SRTP stream! And
this is to protect against an attack where the receiver/victim notifies
the sender/attacker of every auth failure, which is not possible in SRTP
since no such feedback exists. And as John mentioned, the DOS of so many
forged packets and auth failure messages would be a much worse consequence
than compromising the auth tag.

So I would also be fine with only 64 bit auth tags for both GCM and CCM.

AEAD_AES_256_GCM_8/64
AEAD_AES_128_GCM_8/64
AEAD_AES_128_CCM_8/64

If we go this final route, I suggest updating section 14.2 with a table
for 1.5 KB packets (not just 64 KB), and more concrete guidance on what
the security ramifications are. In particular, that these (many) forgeries
can only inject random data since the decryption key is unknown. That is,
they inject a chosen cipher text but a random plain text after decryption
since the decryption key is unknown and not compromised by this auth key
attack. The security ramifications of this auth key attack are minor in my
opinion, especially relative to the major denial-of-service caused by so
many forgeries and auth failure feedback.

I would not be fine with anything less than this. One GCM is not
sufficient, we need both 128 and 256 bit keys. GCM is not sufficient, we
also need CCM (128_8/64).

Mo

On 2/19/15, 11:01 AM, Magnus Westerlund <[email-masked]>
wrote:

On 2015-02-15 15:09, David McGrew wrote:
> will  prioritize simplicity over variety and diversity, I¹m good with

Stephen, WG

Cheers

Magnus Westerlund

[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Feb 2015 12:06:46 +0000

We seem to have opinions all over the map on this one. Sorry for
making life difficult;-) I guess we'll be discussing it on the
informal telechat this Thursday though, so just picking some set
then would seem like the best approach. (I'll still briefly argue
for the minimal set, but I accept we should just pick something
then and be done with this.)

S.

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Tue, 24 Feb 2015 18:07:11 +0000

I would like to point out the strongest argument for the sufficiency of 64
bit auth tags, taken directly from the SRTP RFC.

http://tools.ietf.org/html/rfc3711#section-9.2

   ...when 2^48 SRTP packets or 2^31 SRTCP packets have been secured
   with the same key (whichever occurs before), the key management MUST
   be called to provide new master key(s)…

   Note: in most typical applications (assuming at least one RTCP packet
   for every 128,000 RTP packets), it will be the SRTCP index that first
   reaches the upper limit, although the time until this occurs is very
   long: even at 200 SRTCP packets/sec, the 2^31 index space of SRTCP is
   enough to secure approximately 4 months of communication.

This should make it clear that any potential weakness in GCM auth that
reduces the effective strength of 64 bit auth tags by 7-12 bits (for 2-64
KB packets) is moot due to the SRTCP 31 bit limit and SRTP 48 bit limit.
An attacker would hit rekey criteria before achieving 0.1% chance of a
single successfully forged packet (of chosen cipher text but random plain
text since decryption keys are not compromised). DOS criteria would likely
be hit much sooner at such extreme numbers of packets. Furthermore, this
reduced effective strength of auth tags only applies against attacks which
are anyway impossible in SRTP due to no auth failure feedback.

So 64 bit auth tags should be sufficient for SRTP applications.
(As long as the auth transform has no truncation issues.)

Mo

On 2/23/15, 6:16 PM, Mo Zanaty (mzanaty) <[email-masked]> wrote:

AEAD_AES_256_GCM
AEAD_AES_128_GCM
AEAD_AES_128_CCM_8/64

AEAD_AES_256_GCM_8/64
AEAD_AES_128_GCM_8/64
AEAD_AES_128_CCM_8/64

Mo

Stephen, WG

Cheers

Magnus Westerlund

---

From: John Mattsson <[email-masked]>
Date: Wed, 25 Feb 2015 08:48:47 +0000

I am fine with keeping only the 6 suites suggested by David.

On 2015-02-24 Mo Zanaty wrote:
> I also agree with John that 64 bit auth tags are sufficient for SRTP even using GCM.

The reason GCM_64 was removed was because I pointed out that the draft should follow the NIST requirements in SP 800-38D, Appendix C. Kevin and David chose to remove GCM_64 instead.

Cheers,
John

On 24 Feb 2015, at 19:07, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:

Mo

AEAD_AES_256_GCM
AEAD_AES_128_GCM
AEAD_AES_128_CCM_8/64

AEAD_AES_256_GCM_8/64
AEAD_AES_128_GCM_8/64
AEAD_AES_128_CCM_8/64

Mo

Stephen, WG

Cheers

Magnus Westerlund