Subject: [AVTCORE] Key lifetime in RFC 5764 DTLS-SRTP and RFC 6188 AES-256

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 31 Mar 2017 00:55:05 +0000

The key lifetime in RFC 3711 is 2^48 SRTP packets and 2^31 SRTCP packets, whichever wraps first. My understanding is these limits are due to avoiding IV reuse (48-bit SRTP ROC,SEQ and 31-bit SRTCP index) to avoid a two-time pad, rather than any limits in the underlying block cipher or its key strength.

RFC 5764 DTLS-SRTP specifies the key lifetime as 2^31 for both SRTP and SRTCP. This seems wrong since SRTP should be 2^48 like RFC 3711.

The same issue exists in RFC 6188 AES-256.

Note that 2^31 SRTP packets can be exhausted by real-world video streams (high rate and long duration, but still practical video applications).

After reviewing errata on RFC 5764, none relate to this. RFC 6188 has none filed. I plan to file one on both specs unless I hear otherwise here.

Thanks,
Mo

---

From: Simon Perreault <[email-masked]>
Date: Fri, 31 Mar 2017 08:52:18 -0500

Le 2017-03-30 à 19:55, Mo Zanaty (mzanaty) a écrit :
> The key lifetime in RFC 3711 is 2^48 SRTP packets and 2^31 SRTCP
> packets, whichever wraps first. My understanding is these limits are due
> to avoiding IV reuse (48-bit SRTP ROC,SEQ and 31-bit SRTCP index) to
> avoid a two-time pad, rather than any limits in the underlying block
> cipher or its key strength.
> 
> RFC 5764 DTLS-SRTP specifies the key lifetime as 2^31 for both SRTP and
> SRTCP. This seems wrong since SRTP should be 2^48 like RFC 3711.
> 
> Note that 2^31 SRTP packets can be exhausted by real-world video streams
> (high rate and long duration, but still practical video applications).
> 
> After reviewing errata on RFC 5764, none relate to this. RFC 6188 has
> none filed. I plan to file one on both specs unless I hear otherwise here.

Mo,

I think your reasoning makes sense. I noticed this oddity while
implementing DTLS-SRTP, thought "the ways of the crypto gods are
inscrutable", and decided to use the lower limit. ¯\_(ツ)_/¯

-- 
Simon Perreault
Director of Engineering, Platform | Jive Communications, Inc.
https://jive.com | +1 418 478 0989 ext. 1241 | [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 31 Mar 2017 19:41:25 +0000

Mo,

Curious about why 96 bits were used for the salt in SRTP's use of AES 
GCM rather than the usual 112, I found no reason.

What I did find, though, was this:

     The total number of invocations of the authenticated encryption 
function shall not exceed
     2^32, including all IV lengths and all instances of the 
authenticated encryption function with
     the given key.

That came from Section 8.3 of 
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38D.pdf.

Perhaps that is what drove the key lifetime requirement?

Paul

------ Original Message ------
From: "Mo Zanaty (mzanaty)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 3/30/2017 8:55:05 PM
Subject: [AVTCORE] Key lifetime in RFC 5764 DTLS-SRTP and RFC 6188 
AES-256

>packets, whichever wraps first. My understanding is these limits are 
>due to avoiding IV reuse (48-bit SRTP ROC,SEQ and 31-bit SRTCP index) 
>to avoid a two-time pad, rather than any limits in the underlying block 
>Note that 2^31 SRTP packets can be exhausted by real-world video 
>streams (high rate and long duration, but still practical video 
>applications).
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 31 Mar 2017 21:59:30 +0000

Paul,

That NIST pub is for GCM (RFC 7714) not CM. Also, that section 8.3 does not apply to 96-bit IVs as used in RFC 7714. See the sentence immediately preceding your quote:
"In other words, unless an implementation only uses 96-bit IVs that are generated by the deterministic construction:"

For 96-bit IVs used in RFC 7714, the limit is 2^64 per Appendix B:
"Therefore, the total number of blocks of plaintext and AAD that are protected by invocations of the authenticated encryption function during the lifetime of the key should be limited. A reasonable limit for most applications would be 2^64, consistent with the requirement on the number of invocations in Sec. 8.3."

RFC 7714 GCM has the correct key lifetime of 2^48 SRTP and 2^31 SRTCP packets. It is RFC 5764 DTLS-SRTP and RFC 6188 AES-256 which have the incorrect 2^31 without specifying SRTP and SRTCP separately.

Mo

From: Paul Jones <[email-masked]<mailto:[email-masked]>>
Reply-To: Paul Jones <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 31, 2017 at 3:41 PM
To: mzanaty <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [AVTCORE] Key lifetime in RFC 5764 DTLS-SRTP and RFC 6188 AES-256

Mo,

Curious about why 96 bits were used for the salt in SRTP's use of AES GCM rather than the usual 112, I found no reason.

    The total number of invocations of the authenticated encryption function shall not exceed
    2^32, including all IV lengths and all instances of the authenticated encryption function with
    the given key.

That came from Section 8.3 of http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38D.pdf.

Paul

------ Original Message ------
From: "Mo Zanaty (mzanaty)" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: 3/30/2017 8:55:05 PM
Subject: [AVTCORE] Key lifetime in RFC 5764 DTLS-SRTP and RFC 6188 AES-256

Thanks,
Mo

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 31 Mar 2017 22:07:20 +0000

Adding the RFC authors (EKR for 5764, David for both) to review this before filing the errata.

Mo

From: avt <[email-masked]<mailto:[email-masked]>> on behalf of mzanaty <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 31, 2017 at 5:59 PM
To: Paul Jones <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [AVTCORE] Key lifetime in RFC 5764 DTLS-SRTP and RFC 6188 AES-256

Paul,

Mo

Mo,

Paul

------ Original Message ------
From: "Mo Zanaty (mzanaty)" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: 3/30/2017 8:55:05 PM
Subject: [AVTCORE] Key lifetime in RFC 5764 DTLS-SRTP and RFC 6188 AES-256

Thanks,
Mo

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 31 Mar 2017 22:49:07 +0000

Mo,

Ah, sorry.  I got my wires crossed as I looked at your previous RFC 7714 
message and then saw this one.

Paul

------ Original Message ------
From: "Mo Zanaty (mzanaty)" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 3/31/2017 5:59:30 PM
Subject: Re: [AVTCORE] Key lifetime in RFC 5764 DTLS-SRTP and RFC 6188 
AES-256

>Paul,
>
>That NIST pub is for GCM (RFC 7714) not CM. Also, that section 8.3 does 
>not apply to 96-bit IVs as used in RFC 7714. See the sentence 
>immediately preceding your quote:
>"In other words, unless an implementation only uses 96-bit IVs that are 
>generated by the deterministic construction:"
>
>"Therefore, the total number of blocks of plaintext and AAD that are 
>protected by invocations of the authenticated encryption function 
>during the lifetime of the key should be limited. A reasonable limit 
>for most applications would be 2^64, consistent with the requirement on 
>the number of invocations in Sec. 8.3."
>
>RFC 7714 GCM has the correct key lifetime of 2^48 SRTP and 2^31 SRTCP 
>packets. It is RFC 5764 DTLS-SRTP and RFC 6188 AES-256 which have the 
>incorrect 2^31 without specifying SRTP and SRTCP separately.
>
>Mo
>
>From: Paul Jones <[email-masked]>
>Reply-To: Paul Jones <[email-masked]>
>To: mzanaty <[email-masked]>, "[email-masked]" <[email-masked]>
>>to avoid a two-time pad, rather than any limits in the underlying 
>>block cipher or its key strength.
>>
>>RFC 5764 DTLS-SRTP specifies the key lifetime as 2^31 for both SRTP 
>>and SRTCP. This seems wrong since SRTP should be 2^48 like RFC 3711.
>>