[Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-srtp-ekt-diet-09: (with DISCUSS)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-09: Discuss

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-perc-srtp-ekt-diet/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[this is a placeholder Discuss  to indicate a couple of broad issues early; a full
review and ballot position is forthcoming]

I think  we need to discuss whether the mechanism described in Section 4.1 contains
an EKT-specific extension mechanism or is in fact a more general mechanism for
including extensions in SRTP packets outside the SRTP cryptographic protection.
(If so, we would probably need to Update 3711 to indicate as much, and perhaps allow
for multiple extension types to be present adjacently.)  In particular, how would this
EKT extension interact with any other future mechanism that needs to add data to
SRTP  packets outside the SRTP cryptographic wrapper?

I also think we need to discuss whether it is appropriate to set a precedent that any
standards-track protocol can get a dedicated TLS HandshakeType (noting that this is
a potentially scarce one-octet field.  Would it be more appropriate to define a generic
"key transport" container that can be generally applicable to many protocols, and have
an internal extension point that allows for an SRTP+EKT-specific usage within the
TLS HandshakeType?