Subject: [AVTCORE] Summary of discussion with IESG and call for consensus regarding AES-GCM draft

From: Magnus Westerlund <[email-masked]>
Date: Mon, 2 Mar 2015 12:53:17 +0100

WG,

Last Thursday Kevin Igoe and I participated in a phone conference with
IESG to discuss the way forward with draft-ietf-avtcore-srtp-aes-gcm.

After some discussion the conclusion was the following:

1. Proposal to remove AES-CCM modes from the draft, if clear need arise
a AES-CCM only separate draft can be created. But, that will not be done
without clear motivation for why CCM is needed. So if you think CCM is
required, please step up and comment on this.

2. The AES-GCM draft is proposed to contain the following configurations:

       AEAD_AES_128_GCM     (with 16 byte authentication tag)
       AEAD_AES_128_GCM_64  (with 8 byte authentication tag)
       AEAD_AES_256_GCM     (with 16 byte authentication tag)

If any one in the WG has issues with either of these proposals, please
comment on this no later than 16th of March.

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: John Mattsson <[email-masked]>
Date: Wed, 4 Mar 2015 22:10:39 +0000

On 02 Mar 2015, at 12:53, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:

WG,

Is the proposal then to include the profile from draft-ietf-avtcore-srtp-aes-gcm-12 with a maximum key lifetime  of 2^17 packets? Just so that everybody understands that a rekey would be needed every 43 minutes for a codec with 20 ms payload size.

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: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 5 Mar 2015 03:53:36 +0000

Where did 2^17 come from? For packets around 1KB, the authentication tag strength is only reduced by 6 bits from 64 to 58 bits. SRTCP would rekey after 2^31 packets, giving a 2^-27 probability of a single successful forgery during the key lifetime if all 2^31 packets were forgeries. SRTP would theoretically rekey after 2^48 packets, giving a 2^-10 probability of a single successful forgery during the key lifetime if all 2^48 packets were forgeries, but in reality, SRTCP will always cause rekey first assuming at least 1 RTCP packet for every 2^17 RTP packets.

And this is only for hypothetical attacks which require auth fail feedback per packet which can’t be realized in SRTP. And it requires extreme packet rates causing a denial-of-service far worse than the impact of compromised auth. And even a successful attack can only forge random data since the decryption key is not compromised.

I see no reason to reduce key lifetime below other modes, even under the most paranoid security considerations. This is not a real-world vulnerability in SRTP applications. Thick tinfoil hats are good, but not so thick that they pin your head to the ground.

Mo

On 3/4/15, 5:10 PM, John Mattsson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 5 Mar 2015 04:01:33 +0000

I¹m fine with these proposals. CCM may eventually be needed for some
constrained applications, but there is really no reason to bury it in the
GCM draft, it should live on its own merits in a separate draft if needed.
The GCM options look sufficient.

Mo

On 3/2/15, 6:53 AM, Magnus Westerlund <[email-masked]>
wrote:

WG,

Cheers

Magnus Westerlund

[email-masked]

---

From: John Mattsson <[email-masked]>
Date: Thu, 5 Mar 2015 16:34:32 +0000

On 05 Mar 2015, at 04:53, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:

Where did 2^17 come from?

Nist SP 800-38D, Appendix C (I assume Kevin chosed the longest length).

For packets around 1KB, the authentication tag strength is only reduced by 6 bits from 64 to 58 bits. SRTCP would rekey after 2^31 packets, giving a 2^-27 probability of a single successful forgery during the key lifetime if all 2^31 packets were forgeries. SRTP would theoretically rekey after 2^48 packets, giving a 2^-10 probability of a single successful forgery during the key lifetime if all 2^48 packets were forgeries, but in reality, SRTCP will always cause rekey first assuming at least 1 RTCP packet for every 2^17 RTP packets.

I’m fine with something like that, my only demand is that the draft does not silently ignore the NIST requirements. The draft uses NIST SP 800-38D as the reference for GCM (shouldn’t this be a normative reference just like RFC3610?)

We need to have the discussion you started above, and if the wg agrees, the draft needs to state that the strict NIST requirements does not apply to SRTP, explain why, and state which requirements this puts on packet lengths.

John

Mo

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 5 Mar 2015 17:09:38 +0000

NIST does not say this. There must be some disconnect.

Mo

On Mar 5, 2015, at 11:34 AM, John Mattsson <[email-masked]<mailto:[email-masked]>> wrote:

John

Mo

---

From: John Mattsson <[email-masked]>
Date: Thu, 5 Mar 2015 17:25:37 +0000

On 05 Mar 2015, at 18:09, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:

What do you mean with “this”?

NIST SP 800-38D, Appendix C says “For any implementation that supports 32-bit or 64-bit tags, one of the rows in Table 1 or Table 2, respectively, shall be enforced.”
and one of these rows in Table 2 is "Maximum Invocations of the Authenticated Decryption Function = 2^17”

John

Mo

John

Mo

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 5 Mar 2015 18:09:34 +0000

Here is Table 2 from NIST SP 800-38D Appendix C.
http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf

Table 2: Constraints with 64-bit Tags
Maximum Combined Length of the Ciphertext and AAD In a Single Packet (bytes),
Maximum Invocations of the Authenticated Decryption Function
2^15, 2^32
2^17, 2^29
2^19, 2^26
2^21, 2^23
2^23, 2^20
2^25, 2^17

The last row with packet size of 2^25 bytes is not relevant for SRTP, so 2^17 packets per key makes no sense for SRTP. The relevant packet size is 2^10 bytes, which can be extrapolated from this table to be ~2^40 max invocations (packets), which already exceeds SRTCP key lifetime (2^31 packets) and approaches SRTP key lifetime (2^48 packets). The target probability of a single successful forgery after this max invocations of forged packets used to arrive at these recommendations is not specified, but can be deduced to be ~2^-18. If the target probability is 2^-10, both the SRTP and SRTCP key lifetimes are exceeded.

So even per NIST, there is no need to reduce SRTCP key lifetime, and SRTP key lifetime should only be reduced to 2^40 for 2^-18 target probability of a single successful forgery in this lifetime, or no need to reduce at all for 2^-10 target probability. I suggest the latter, no reduction in SRTP/SRTCP key lifetime.

Mo

On 3/5/15, 12:25 PM, John Mattsson <[email-masked]<mailto:[email-masked]>> wrote:

John

Mo

John

Mo

---

From: John Mattsson <[email-masked]>
Date: Thu, 5 Mar 2015 18:56:13 +0000

On 05 Mar 2015, at 19:09, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:

Mo

I agree, that is a much better tradeoff (reducing the payload length instad of key lifetime). If there are applications using large payload lengths, they could chose a larger tag length.

On 05 Mar 2015, at 04:53, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:
And this is only for hypothetical attacks which require auth fail feedback per packet which can’t be realized in SRTP.

I don’t know if we can make any strong feedback assumptions for RTP header extensions, they don't even require standardisation.

My suggestion would be to simply chose (2^15, 2^32), then we would follow NIST and could still send 2^47 B = 128 TB of data.

John

John

Mo

John

Mo

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Mar 2015 08:44:45 +0100

WG,

I note that the deadline is past and no one has opposed the proposal.
There was discussion about the payload length vs number of payloads that
could be sent while staying within NIST's recommendation for the
algorithm when using the 64 bit authentication tag option. To my
understanding the discussion concluded in a recommendation to make clear
that as long as you don't have payloads longer than 2^15 one only need
to rekey as often as SRTP requires due to wrapping of extended sequence
number used.

Authors, please prepare an update draft with only AES-GCM and submit it
as soon as possible.

Cheers

Magnus Westerlund
(As WG chair)

-- 

Magnus Westerlund

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Tue, 17 Mar 2015 17:16:55 +0000

So let it be written so let it be done.  I'm currently working on producing the test
vectors with copious intermediate outputs that one of the contributors requested.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, March 17, 2015 3:45 AM
> To: IETF AVTCore WG
> Cc: [email-masked]
> Subject: Re: [AVTCORE] Summary of discussion with IESG and call for consensus regarding AES-GCM draft
> 
> WG,
> 
> There was discussion about the payload length vs number of payloads that could be sent while staying within NIST's recommendation
> for the algorithm when using the 64 bit authentication tag option. To my understanding the discussion concluded in a
> recommendation to make clear that as long as you don't have payloads longer than 2^15 one only need to rekey as often as SRTP
> requires due to wrapping of extended sequence number used.
> 
> Authors, please prepare an update draft with only AES-GCM and submit it as soon as possible.
> 
> Cheers
> 
> Magnus Westerlund
> (As WG chair)
> 
> > 1. Proposal to remove AES-CCM modes from the draft, if clear need
> > arise a AES-CCM only separate draft can be created. But, that will not
> > be done without clear motivation for why CCM is needed. So if you
> > think CCM is required, please step up and comment on this.
> >
> > Audio/Video Transport Core Maintenance [email-masked]