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

["Mo Zanaty (mzanaty)" <[e-mail]>]

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