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

[John Mattsson <[e-mail]>]

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

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

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


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


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

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

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

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


On 05 Mar 2015, at 04:53, Mo Zanaty (mzanaty) <[e-mail]<mailto:[e-mail]>> 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.

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.

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


On 3/4/15, 5:10 PM, John Mattsson <[e-mail]<mailto:[e-mail]>> wrote:
On 02 Mar 2015, at 12:53, Magnus Westerlund <[e-mail]<mailto:[e-mail]>> wrote:
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)
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.