Address minor cryptographic points from EKR

[bifurcation]

In his response to the SFrame adoption call, @ekr made a couple of points regarding the cryptographic constructions in SFrame, which still apply to the current draft. They are presented here in blockquotes, with my comments below.

I do think it would be useful to explain the extent to which this depends on SRTP for security, if at all.

SFrame doesn't depend on SRTP for security, so I don't think any comment is needed here.

A 4 byte tag is pretty short.

Audio packets are pretty short, so media folks are sensitive to percentage overhead -- I have had to argue some folks up from zero. You can also read "4 byte tag" as "2^{-32} expected forgery rate", which is a pretty small disruption in the scheme of an audio stream.

What's the reason for specifying anything with SHA-512 as the KDF?

Cargo-cult level-matching. Looking at other cipher suites with AES-256 and SHA-based KDFs, MLS uses SHA-512, but TLS and IKE use SHA-384. I would be open to suggestions here.

[bifurcation]

Interim 2023-09-13:

• RLB: Note that SRTP does protect the KID/CTR header from inspection. It is integrity-protected by inclusion in AAD.
  • TODO(RLB): Add a note to security considerations
• Re: 4-byte tag
  • Marta seems to recall that some NIST/something docs have a 4-byte minimum tag size
  • Martin notes that in the E2EE case, forgery attacks would be by HBH-trusted actors
  • No action
• Re: SHA-512
  • RLB: No speed consideration for SHA-512, since it's just in KDF
  • Brendan: Maybe it's salient that SHA-384 is truncated SHA-512?
  • No other strong opionions, leaving as-is