Subject: [AVTCORE] Benjamin Kaduk's No Objection on draft-ietf-avtcore-multiplex-guidelines-12: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 16 Jun 2020 20:32:53 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-avtcore-multiplex-guidelines-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my Discuss point.

A couple things I noticed while reviewing the diff:

Section 3.1's "might not be the choice suitable in another
situation or combination of reasons" seems like it's comparing things of different types.

Section 4.3.1 now has:

   SRTP [RFC3711] as specified uses per SSRC unique keys, however the
   original assumption was a single session master key from which SSRC
   specific RTP and RTCP keys where derived.  However, that assumption
   was proven incorrect, as the application usage and the developed key-
   mamangement mechanisms have chosen many different methods for
   ensuring SSRC unique keys.  The key-management functions have

I didn't try to look at RFC 3711 and see if there was now-believed-to-be-incorrect
text in need of an update or not.  I guess any potential violations of 3711 are
in the "application usage and the developed-key-management techniques" that
we describe, not in this document itself, so there's not really a question of this
document being in conflict with 3711.
Also, nit: s/mamangement/management/

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Jun 2020 08:04:57 +0000

On Tue, 2020-06-16 at 20:32 -0700, Benjamin Kaduk via Datatracker wrote:
> Please refer to 
> https://protect2.fireeye.com/v1/url?k=0b08921f-55b80f87-0b08d284-861fcb972bfc-1bcefe42a2cf38ea&q=1&e=52b5d9a4-3617-40b8-940a-53b949d7c425&u=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
https://protect2.fireeye.com/v1/url?k=3b2e741d-659ee985-3b2e3486-861fcb972bfc-fb880de6ca902fcc&q=1&e=52b5d9a4-3617-40b8-940a-53b949d7c425&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-avtcore-multiplex-guidelines%2F

Ok, will try to keep this in mind in AUTH48 and unless the RFC-editors already
catch it. 

> document being in conflict with 3711.

So RFC 3711 for example contains the below statement, and if you read more in
section 7 and 8 I think it is fairly clear that the original intention was a
single master key per time periods. 

7.1.  Key derivation

   Key derivation reduces the burden on the key establishment.  As many
   as six different keys are needed per crypto context (SRTP and SRTCP
   encryption keys and salts, SRTP and SRTCP authentication keys), but
   these are derived from a single master key in a cryptographically
   secure way.  Thus, the key management protocol needs to exchange only
   one master key (plus master salt when required), and then SRTP itself
   derives all the necessary session keys (via the first, mandatory
   application of the key derivation function).

So there is one keymanagement solution that is capable of proving only a single
master key, and that is MIKEY in some mode, and something that is requried in
the Broadcast/Multicast keying cases. However, Security Descriptions and DTLS-
SRTP both result in per endpoint master keys. So I would most definitely blame
the keymanagement mechanism. The impact of this I think where minor, simply to
add additional master key selectors in the security context handling so that one
can determine when a new SSRC is received or locally generated that one picks
the right master key to derive the per SSRC keys. 

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------