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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-10: 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:
----------------------------------------------------------------------

The -10 introduced text implying that the DTLS 1.3 retransmission rules
are normative, that is in conflict with the existing text indicating
that DTLS 1.2 retransmission rules are normative (see COMMENT).

The DTLS 1.3 Ack message is a dedicated content-type, not a
handshake-type.

I support Alexey's Discuss about the ABNF breakage.
Note that there is a similar issue in the names of the TLS extensions in
the IANA considerations -- the names now include "\_" instead of just "_".


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

This document is written under the assumption that the EKT content will
be the only content after the encrypted SRTP payload (and authentication
tag, if present).  That's true at present, of course, but I would still
like to see a little discussion of how it might coexist with other SRTP
extensions that place content as a trailer (both would need to be
parseable from the tail of the content and have a length field; and they
woule either need to share a message-type namespace or have a profile
specification to indicate what order they appear in), though the
discussion that already occurred suffices to make this not a
Discuss-level point.

Section 5 has:

   the DTLS-SRTP peer in the server role to the client.  This allows
   those peers to process EKT keying material in SRTP (or SRTCP) and
   retrieve the embedded SRTP keying material.  This combination of

but in Section 4 we say that "use with SRTCP would be similar, but is
reserved for a future specification".  (There may be one or two other
places that have text placing SRTCP on the same footing as SRTP even
though they are not, at present.)

Also section 5

   In cases where the DTLS termination point is more trusted than the
   media relay, the protection that DTLS affords to EKT key material can
   allow EKT keys to be tunneled through an untrusted relay such as a
   centralized conference bridge.  For more details, see
   [I-D.ietf-perc-private-media-framework].

I did not chase the reference, but it seems like this sentence might
apply equally for "EKT keys to be tunneled" and "SRTP master keys to be
tunneled".  I trust the authors to say what they mean :)

Section 5.2.2

What do I do when I receive an EKTKey containing an ekt_spi value for
which I already have stored parameters?

   When an EKTKey is received and processed successfully, the recipient
   MUST respond with an Ack handshake message as described in Section 7
   of [I-D.ietf-tls-dtls13].  The EKTKey message and Ack MUST be

Ack is a content type, not a handshake type.  (Per DISCUSS point)

   When an EKTKey is received and processed successfully, the recipient
   MUST respond with an Ack handshake message as described in Section 7
   of [I-D.ietf-tls-dtls13].  The EKTKey message and Ack MUST be
   retransmitted following the rules in Section 4.2.4 of [RFC6347].

It's a little weird to cite DTLS 1.3 for the Ack message but then revert
to DTLS 1.2 for the retransmission schedule...

   EKT MAY be used with versions of DTLS prior to 1.3.  In such cases,
   the Ack message is still used to provide reliability.  Thus, DTLS
   implementations supporting EKT with DTLS pre-1.3 will need to have
   explicit affordances for sending the Ack message in response to an
   EKTKey message, and for verifying that an Ack message was received.
   The retransmission rules for both sides are the same as in DTLS 1.3.

...but here we say that the DTLS 1.3 retransmission rules are
authoritative.  (per DISCUSS)

Section 6

   With EKT, each SRTP sender and receiver MUST generate distinct SRTP
   master keys.  This property avoids any security concern over the re-

Er, does an SRTP receiver have a master key ("what does it encrypt if
it's not sending anything")?

   In some systems, when a member of a conference leaves the
   conferences, the conferences is rekeyed so that member no longer has
   the key.  When changing to a new EKTKey, it is possible that the
   attacker could block the EKTKey message getting to a particular
   endpoint and that endpoint would keep sending media encrypted using
   the old key.  To mitigate that risk, the lifetime of the EKTKey MUST
   be limited using the ekt_ttl.

Do we want to give any concrete guidance about ekt_ttl values?