I’m having trouble understanding the relationship between this work and SRTP without making assumptions. Section 1.3 notes that there is a design goal to build on top of SRTP and to have simple SRTP interactions. Section 3 also says the design goal is to “reuse the existing SRTP framework.” Finally, Section 6.2 and 6.3 says ”[t]he encryption (or decryption) procedure is identical to that of [RFC3711] except for the Encrypted Portion of the SRTP packet.”
I believe the correct read is that “do everything from SRTP unless noted as different here”. However, saying “encryption and description procedures" per Sections 6.2/6.3 doesn’t capture that for me. This leaves open questions about key management, establish and maintaining state for cryptographic contexts, MTI algorithms, etc.
The text would benefit from being explicit on what behavior “a=cryptex” behavior reuses from SRTP. I don’t believe that changes any of the expected core mechanics.
I’m having trouble understanding the relationship between this work and SRTP without making assumptions. Section 1.3 notes that there is a design goal to build on top of SRTP and to have simple SRTP interactions. Section 3 also says the design goal is to “reuse the existing SRTP framework.” Finally, Section 6.2 and 6.3 says ”[t]he encryption (or decryption) procedure is identical to that of [RFC3711] except for the Encrypted Portion of the SRTP packet.”
I believe the correct read is that “do everything from SRTP unless noted as different here”. However, saying “encryption and description procedures" per Sections 6.2/6.3 doesn’t capture that for me. This leaves open questions about key management, establish and maintaining state for cryptographic contexts, MTI algorithms, etc.
The text would benefit from being explicit on what behavior “a=cryptex” behavior reuses from SRTP. I don’t believe that changes any of the expected core mechanics.