Draft: draft-ietf-perc-srtp-ekt-diet

Commentary: Looks good ... one small typo nit ..
Mailing list commentary: Hi , This is my AD Evaluation of draft - ietf - perc - srtp - ekt - diet-08 . The document is mostly in good shape . It ’s easy to read and understand . However , I have a few substantive comments / questions and some editorial comments . I would like to at least discuss the substantive comments before going to IETF LC . Thanks ! .
Paragraph (version A):
One way to use this is described in the architecture defined by I-
D.ietf-perc-private-media-framework.  Each participant in the
conference forms a DTLS-SRTP connection to a common key distributor
that distributes the same EKTKey to all the endpoints.  Then each
endpoint picks their own SRTP master key for the media they send.
When sending media, the endpoint also includes the SRTP master key
encrypted with the EKTKey in the SRTP packet.  This allows all the
endpoints to decrypt the media.
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
Paragraph (version B):
One way to use this is described in the architecture defined by I-
D.ietf-perc-private-media-framework.  Each participant in the
conference forms a DTLS-SRTP connection to a common key distributor
that distributes the same EKTKey to all the endpoints.  Then each
endpoint picks its own SRTP master key for the media they send.  When
sending media, the endpoint also includes the SRTP master key
encrypted with the EKTKey in the SRTP packet.  This allows all the
endpoints to decrypt the media.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Paragraph (version A):
The EKTField uses the format defined below for the FullEKTField and
ShortEKTField.
Paragraph (version B):
The EKTField uses the format defined in tag-format-base for the
FullEKTField and ShortEKTField.
Paragraph (version B):
Outbound packets SHOULD continue to use the old SRTP Master Key for
250 ms after sending any new key.  This gives all the receivers in
the system time to get the new key before they start receiving media
encrypted with the new key.
Paragraph (version A):
The value of the EKTCiphertext field is identical in successive
packets protected by the same EKT parameter set and the same SRTP
master key, and ROC.  This ciphertext value MAY be cached by an SRTP
receiver to minimize computational effort by noting when the SRTP
master key is unchanged and avoiding repeating the steps defined in
{#pkt_proc}.
Paragraph (version A):
The receiver may want to have a sliding window to retain old SRTP
Master Keys (and related context) for some brief period of time, so
that out of order packets can be processed as well as packets sent
during the time keys are changing.
Paragraph (version A):
When receiving a new EKTKey, implementations need to use the ekt_ttl
to create a time after which this key cannot be used and they also
need to create a counter that keeps track of how many times the key
has been used to encrypt data to ensure it does not exceed the T
value for that cipher (see {#cipher}).  If either of these limits are
exceeded, the key can no longer be used for encryption.  At this
point implementation need to either use the call signaling to
renegotiate a new session or need to terminate the existing session.
Terminating the session is a reasonable implementation choice because
these limits should not be exceeded except under an attack or error
condition.
Paragraph (version B):
The value of the EKTCiphertext field is identical in successive
packets protected by the same EKT parameter set and the same SRTP
master key, and ROC.  SRTP senders and receivers MAY cache an
EKTCiphertext value to optimize processing in cases where the master
key hasn't changed.  Instead of encrypting and decrypting, senders
can simply copy the pre-computed value and receivers can compare a
received EKTCiphertext to the known value.
Paragraph (version B):
outbound-processing recommends that SRTP senders continue using an
old key for some time after sending a new key in an EKT tag.
Receivers that wish to avoid packet loss due to decryption failures
MAY perform trial decryption with both the old key and the new key,
keeping the result of whichever decryption succeeds.  Note that this
approach is only compatible with SRTP transforms that include
integrity protection.
Paragraph (version B):
When receiving a new EKTKey, implementations need to use the ekt_ttl
field (see ekt_key) to create a time after which this key cannot be
used and they also need to create a counter that keeps track of how
many times the key has been used to encrypt data to ensure it does
not exceed the T value for that cipher (see {#cipher}).  If either of
these limits are exceeded, the key can no longer be used for
encryption.  At this point implementation need to either use the call
signaling to renegotiate a new session or need to terminate the
existing session.  Terminating the session is a reasonable
implementation choice because these limits should not be exceeded
except under an attack or error condition.
Paragraph (version A):
EKT SHOULD be used over SRTP, and other specification MAY define how
to use it over SRTCP.  SRTP is preferred because it shares fate with
the transmitted media, because SRTP rekeying can occur without
concern for RTCP transmission limits, and to avoid SRTCP compound
packets with RTP translators and mixers.
Paragraph (version B):
This document defines the use of EKT with SRTP.  Its use with SRTCP
would be similar, but is reserved for a future specification.  SRTP
is preferred for transmitting key material because it shares fate
with the transmitted media, because SRTP rekeying can occur without
concern for RTCP transmission limits, and because it avoids the need
for SRTCP compound packets with RTP translators and mixers.
Paragraph (version A):
There are three cases to consider.  The first case is a new sender
joining a session which needs to communicate its SRTP master key to
all the receivers.  The second case is a sender changing its SRTP
master key which needs to be communicated to all the receivers.  The
third case is a new receiver joining a session already in progress
which needs to know the sender's SRTP master key.
Paragraph (version B):
There are three cases to consider.  The first case is a new sender
joining a session, which needs to communicate its SRTP master key to
all the receivers.  The second case is a sender changing its SRTP
master key which needs to be communicated to all the receivers.  The
third case is a new receiver joining a session already in progress
which needs to know the sender's SRTP master key.
Paragraph (version A):
In the context of a multi-party SRTP session in which each endpoint
performs a DTLS handshake as a client with a central DTLS server, the
extensions defined in this session allows the DTLS server to set a
common EKTKey for all participants.  Each endpoint can then use EKT
tags encrypted with that common key to inform other endpoint of the
keys it uses to protect SRTP packets.  This avoids the need for many
individual DTLS handshakes among the endpoints, at the cost of
preventing endpoints from directly authenticating one another.
Paragraph (version B):
In the context of a multi-party SRTP session in which each endpoint
performs a DTLS handshake as a client with a central DTLS server, the
extensions defined in this document allow the DTLS server to set a
common EKTKey for all participants.  Each endpoint can then use EKT
tags encrypted with that common key to inform other endpoint of the
keys it uses to protect SRTP packets.  This avoids the need for many
individual DTLS handshakes among the endpoints, at the cost of
preventing endpoints from directly authenticating one another.
Paragraph (version A):
EKT inherits the security properties of the DTLS-SRTP (or other)
keying it uses.
Paragraph (version B):
EKT inherits the security properties of the the key management
protocol that is used to establish the EKTKey, e.g., the DTLS-SRTP
extension defined in this document.
Paragraph (version A):
An attacker could send packets containing a FullEKTField, in an
attempt to consume additional CPU resources of the receiving system
by causing the receiving system will decrypt the EKT ciphertext and
detect an authentication failure.  In some cases, caching the
previous values of the Ciphertext as described in inbound-impl-notes
helps mitigate this issue.
Paragraph (version B):
An attacker could send packets containing a FullEKTField, in an
attempt to consume additional CPU resources of the receiving system
by causing the receiving system to decrypt the EKT ciphertext and
detect an authentication failure.  In some cases, caching the
previous values of the Ciphertext as described in inbound-impl-notes
helps mitigate this issue.
Paragraph (version B):
In a similar vein, EKT has no replay protection, so an attacker could
implant improper keys in receivers by capturing EKTCiphertext values
encrypted with a given EKTKey and replaying them in a different
context, e.g., from a different sender.  When the underlying SRTP
transform provides integrity protection, this attack will just result
in packet loss.  If it does not, then it will result in random data
being fed to RTP payload processing.  An attacker that is in a
position to mount these attacks, however, could achieve the same
effects more easily without attacking EKT.
Paragraph (version A):
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
SHOULD be limited using the ekt_ttl.
Paragraph (version B):
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.
Paragraph (version A):
Considerations for this type of extension are described in Section 5
of RFC4366 and requires "IETF Consensus".
Paragraph (version A):
This registry was defined in Section 12 of RFC5246 and requires
"Standards Action".