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

[John Mattsson <[e-mail]>]

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.