[Ballot comment]
Thank you for the work put into this document.  Please find below two non-blocking questions.

NB: the document shepherd write-up should be updated with the responsible AD ;-)

Regards,

-éric

About section 4.3.1

What is a "packet" in the context of "appended to the packet"? Is it the UDP payload ? Should the UDP length be increased? is it the layer-2 frame ?

I also wonder whether 250 msec is enough in all case... Unsure whether SRTP is only used in real-time communication (for info, just reviewed 2 I-D from Delay Tolerant Network... so I may be biased)

[Ballot comment]
Note to self: make sure editors look/respond to Adam’s and Ben’s comments.

Old comments preserved for posterity. I didn't check if they still apply:

I share Benjamin's concern about extensibility.

In 4.4.1:

  The default EKT Cipher is the Advanced Encryption Standard (AES) Key
  Wrap with Padding [RFC5649] algorithm.  It requires a plaintext
  length M that is at least one octet, and it returns a ciphertext with
  a length of N = M + (M mod 8) + 8 octets.

I started looking at RFC 5649. Maybe I was tired and my math was wrong, but I couldn't figure out how you came up with the N value above.
In particular, where is the "+ 8" coming from?

In 6:

  An attacker who tampers with the bits in FullEKTField can prevent the
  intended receiver of that packet from being able to decrypt it.  This
  is a minor denial of service vulnerability.  Similarly the attacker
  could take an old FullEKTField from the same session and attach it to
  the packet.  The FullEKTField would correctly decode and pass
  integrity checks.  However, the key extracted from the FullEKTField ,
  when used to decrypt the SRTP payload, would be wrong and the SRTP
  integrity check would fail.  Note that the FullEKTField only changes
  the decryption key and does not change the encryption key.  None of
  these are considered significant attacks as any attacker that can
  modify the packets in transit and cause the integrity check to fail.

The last sentence seems to be incomplete. Did you mean "can" instead of the last "and"?

[Ballot comment]
We say that EKT can work well in scenarios such as the PERC private media framework,
and in the security considerations we give some information about concerns/caveats with
respect to EKT usage in terms of the low-level cryptographic properties.  Do we want to
give some high-level advice about deployment scenarios in which EKT does not make
sense?

I also wonder if the "ekt" name is a little generic for the TLS codepoints being requested,
as opposed to something involving "srtp_ekt", but that's basically cosmetic.

Updating to include my previous comments, since (as for Adam) they largely seem to have
not been acted upon:

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?

[Ballot discuss]
I think there are an important discrpency between the figure and the ABNF for the full EKT message in section 4.1:

Figure 1:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                              :
    :                        EKT Ciphertext                        :
    :                                                              :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Security Parameter Index    | Length                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 0 0 0 1 0|
    +-+-+-+-+-+-+-+-+

The ABNF parts that appears relevant:

    EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext)
    Epoch = 2BYTE
    SPI = 2BYTE

    FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull

Note that the above ABNF states that the SPI is followed by a 16-bit Epoch field prior to the length field.

Can you please ensure that this discrepancy is clarified.

[Ballot comment]
The document appears to have already gotten significant review with iterative updates.

Section 5.2.
  If an EKTKey message is received that cannot be processed, then the
  recipient MUST respond with an appropriate DTLS alert.

Is there any more specificity that can be provided on which DTLS alert might be appropriate?

[Ballot comment]
Re-sending my initial comments, as only one of the 17 were addressed
in subsequent revisions. While no single comment rises to the level of
a DISCUSS-worthy issue, several of these are moderately severe. I would
appreciate either a response to each comment, or a corresponding
change in the document.

---------------------------------------------------------------------------

Thanks to the work that everyone has put in on getting an EKT mechanism
specified and finalized. I have a handful of comments that I would like to see
considered prior to publication of the document.

---------------------------------------------------------------------------

§1:

>  EKT provides a way for an SRTP session participant, to securely
>  transport its SRTP master key and current SRTP rollover counter to
>  the other participants in the session.

Nit: "...participant to securely..."

---------------------------------------------------------------------------

§4.1:

>  EKTMsgTypeExtension = %x03-FF

Shouldn't this be "%x01 / %x03-ff" ?

>  SRTPMasterKeyLength = BYTE
>  SRTPMasterKey = 1*256BYTE

I think this either needs to be "1*255BYTE", or we need text that explicitly
indicates that an SRTPMasterKeyLength value of 0x00 means "256 bytes." Probably
the former.

I think this is even further constrained by the fact that EKTCiphertext is
limited to 256 bytes, and contains the SRTPMasterKeyLength, SRTPMasterKey,
SSRC, and ROC (and is not compressed) -- which means the SRTPMasterKeyLength
can't be more than (256 - 1 - 4 - 4 =) 247 bytes. So perhaps "1*247BYTE" is
more appropriate?

---------------------------------------------------------------------------

§4.2.1:

>  The creation of the EKTField MUST precede the normal SRTP
>  packet processing.

Why? This seems unnecessary and unnecessarily complicated. If the order of
operations has an impact on the bits on the wire (I don't see how it does?),
then please include some explanatory text here that clarifies the reason for
this constraint.

---------------------------------------------------------------------------

§4.2.1:

>  When a packet is sent with the ShortEKTField, the ShortEKFField is
>  simply appended to the packet.

Nit: s/ShortEKFField/ShortEKTField/

---------------------------------------------------------------------------

§4.2.1:

>  5.  If the SSRC in the EKTPlaintext does not match the SSRC of the
>      SRTP packet received, then all the information from this
>      EKTPlaintext MUST be discarded and the following steps in this
>      list are skipped.

I can see implementors easily interpreting this as requiring them to discard
the RTP payload as well. If that's not the intention (I don't think it is),
consider adding text like "The FullEKTField is removed from the packet then
normal SRTP or SRTCP processing occurs."

---------------------------------------------------------------------------

§4.3:

>  Section 4.2.1 recommends that SRTP senders continue using an old key
>  for some time after sending a new key in an EKT tag.

This is the first appearance of the phrase "EKT tag," which never seems to be
properly defined. I presume this is meant to be the combination of the EKT
Ciphertext and the SPI?

In any case, please clearly define this term somewhere, preferably before using
it the first time.

---------------------------------------------------------------------------

§4.3:

>  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 ).

The parenthetical phrase appears to be missing something here.

>  If
>  either of these limits are exceeded, the key can no longer be used

Nit: "...either... is exceeded..."

>  for encryption.  At this point implementation need to either use the

Nit: "...implementations need..."

---------------------------------------------------------------------------

§4.5:

>  If a source has its EKTKey changed by the key management, it MUST
>  also change its SRTP master key

I suppose it's not terribly important for interop, but the implication that this
change takes place immediately seems to contradict the 250 ms period specified
in §4.2.1. Perhaps a few words here about how these two normative statements
are intended to interact would save implementors a bit of grief.

---------------------------------------------------------------------------

§4.6:

>  This document defines the use of EKT with SRTP.  Its use with SRTCP
>  would be similar, but is reserved for a future specification.

After reading this far, I was quite surprised to find this qualification. If
this is the intention for this document, please adjust the rest of the text to
match. Some examples follow.

>  The following shows the syntax of the EKTField expressed in ABNF
>  [RFC5234].  The EKTField is added to the end of an SRTP or SRTCP
>  packet.
-----
>  Rollover Counter (ROC): On the sender side, this is set to the
>  current value of the SRTP rollover counter in the SRTP/SRTCP context
>  associated with the SSRC in the SRTP or SRTCP packet.
-----
>  1.  The final byte is checked to determine which EKT format is in
>      use.  When an SRTP or SRTCP packet contains a ShortEKTField, the
>      ShortEKTField is removed from the packet then normal SRTP or
>      SRTCP processing occurs.
-----
>      The reason for
>      using the last byte of the packet to indicate the type is that
>      the length of the SRTP or SRTCP part is not known until the
>      decryption has occurred.
-----
>  7.  At this point, EKT processing has successfully completed, and the
>      normal SRTP or SRTCP processing takes place.
-----
>  This allows
>  those peers to process EKT keying material in SRTP (or SRTCP) and
>  retrieve the embedded SRTP keying material.

---------------------------------------------------------------------------

§4.7:

>    To accommodate packet loss, it is
>    RECOMMENDED that three consecutive packets contain the
>    FullEKTField be transmitted.

Nit: "...containing..." (alternately, remove "be transmitted" -- both make a
grammatically correct sentance)

More substantially -- under "New sender:", I'm a little surprised that there
isn't any mention of other senders re-keying in response to a new sender
joining. In the vast majority of conferences, when a sender joins, that same
entity generally will also be a receiver. It seems this should trigger other
senders to include the key in their next packet.

---------------------------------------------------------------------------

§4.7:

>  Rekey:
>    By sending EKT tag over SRTP, the rekeying event shares fate with
>    the SRTP packets protected with that new SRTP master key.

Is this actually true? Going back to the 250 ms period specified in §4.2.1, it
seems that the master key is sent out in packets pretty far removed from those
it actually protects.

Between this and the inconsistency I mention in §4.5 above, this increasingly
feels like maybe there were two different ways of reasoning about the timing
of sending a master key versus the timing of actually using it. Does the text
in §4.2.1 perhaps represent an outdated notion of how this is intended to
work?

---------------------------------------------------------------------------

§4.7:

>    If sending audio and video, the RECOMMENDED
>    frequency is the same as the rate of intra coded video frames.  If
>    only sending audio, the RECOMMENDED frequency is every 100ms.

Is this "100ms" correct?  Assuming, say, the use of Opus at voice quality with
20 ms packets, this is taking packets on the order of 40 bytes in length and
tacking on something like 20 to 30 bytes to every fifth packet. That's an
increase in overall stream size on the order of roughly 15% to 20%.

At the same time, when using real-time video, intra frames are going to happen
roughly every 500 ms to 1500 ms. If a cadence on that order is okay for
audiovisual streams, I have to imagine it's okay for audio streams.

So, to clarify: is this "100ms" a typo for "1000 ms"?

---------------------------------------------------------------------------

§7.2:

>                  +----------+-------+---------------+
>                  | Name    | Value | Specification |
>                  +----------+-------+---------------+
>                  | AESKW128 |    1 | RFCAAAA      |
>                  | AESKW256 |    2 | RFCAAAA      |
>                  | Reserved |  255 | RFCAAAA      |
>                  +----------+-------+---------------+
>
>                        Table 3: EKT Cipher Types

Section 5.2.1 reserves "0" as well. I suspect we want to replicate that
reservation in this table.

[Ballot comment]
We say that EKT can work well in scenarios such as the PERC private media framework,
and in the security considerations we give some information about concerns/caveats with
respect to EKT usage in terms of the low-level cryptographic properties.  Do we want to
give some high-level advice about deployment scenarios in which EKT does not make
sense?

I also wonder if the "ekt" name is a little generic for the TLS codepoints being requested,
as opposed to something involving "srtp_ekt", but that's basically cosmetic.

[Ballot comment]
I need one more review from IESG of this document.

Old comments preserved for posterity. I didn't check if they still apply:

I share Benjamin's concern about extensibility.

In 4.4.1:

  The default EKT Cipher is the Advanced Encryption Standard (AES) Key
  Wrap with Padding [RFC5649] algorithm.  It requires a plaintext
  length M that is at least one octet, and it returns a ciphertext with
  a length of N = M + (M mod 8) + 8 octets.

I started looking at RFC 5649. Maybe I was tired and my math was wrong, but I couldn't figure out how you came up with the N value above.
In particular, where is the "+ 8" coming from?

In 6:

  An attacker who tampers with the bits in FullEKTField can prevent the
  intended receiver of that packet from being able to decrypt it.  This
  is a minor denial of service vulnerability.  Similarly the attacker
  could take an old FullEKTField from the same session and attach it to
  the packet.  The FullEKTField would correctly decode and pass
  integrity checks.  However, the key extracted from the FullEKTField ,
  when used to decrypt the SRTP payload, would be wrong and the SRTP
  integrity check would fail.  Note that the FullEKTField only changes
  the decryption key and does not change the encryption key.  None of
  these are considered significant attacks as any attacker that can
  modify the packets in transit and cause the integrity check to fail.

The last sentence seems to be incomplete. Did you mean "can" instead of the last "and"?

[Ballot comment]
Old comments preserved for posterity. I didn't check if they still apply:

I share Benjamin's concern about extensibility.

In 4.4.1:

  The default EKT Cipher is the Advanced Encryption Standard (AES) Key
  Wrap with Padding [RFC5649] algorithm.  It requires a plaintext
  length M that is at least one octet, and it returns a ciphertext with
  a length of N = M + (M mod 8) + 8 octets.

I started looking at RFC 5649. Maybe I was tired and my math was wrong, but I couldn't figure out how you came up with the N value above.
In particular, where is the "+ 8" coming from?

In 6:

  An attacker who tampers with the bits in FullEKTField can prevent the
  intended receiver of that packet from being able to decrypt it.  This
  is a minor denial of service vulnerability.  Similarly the attacker
  could take an old FullEKTField from the same session and attach it to
  the packet.  The FullEKTField would correctly decode and pass
  integrity checks.  However, the key extracted from the FullEKTField ,
  when used to decrypt the SRTP payload, would be wrong and the SRTP
  integrity check would fail.  Note that the FullEKTField only changes
  the decryption key and does not change the encryption key.  None of
  these are considered significant attacks as any attacker that can
  modify the packets in transit and cause the integrity check to fail.

The last sentence seems to be incomplete. Did you mean "can" instead of the last "and"?

[Ballot comment]
Thank you for addressing my Discuss points!

Original COMMENT preserved below for posterity.

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?

[Ballot 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 "_".

[Ballot 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?

[Ballot discuss]
Thanks for the updates in the -10; we're  making progress.  I think there
are still some issues left to resolve, though.

My previous position had:

"""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 think I remember having such a discussion, but cannot find any record of
it.  Does anyone have a pointer handy (or a corrective to my memory)?

Similarly, I don't remember any discussion on:

"""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?"""

[IANA says they're okay now]

[Ballot discuss]
Thanks for the updates in the -10; we're  making progress.  I think there
are still some issues left to resolve, though.

My previous position had:

"""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 think I remember having such a discussion, but cannot find any record of
it.  Does anyone have a pointer handy (or a corrective to my memory)?

Similarly, I don't remember any discussion on:

"""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?"""

We are also still waiting on IANA, if I understand correctly.  I do not see
any indication that the needed expert review for TLS ExtensionType
allocation has been requested (the authors should initiate this, per RFC
8447), and there may have been other matters that needed clarification.

[Ballot comment]
[original comment section unchanged; contents likely stale]

There is no cryptographic binding between the EKTCiphertext and the main
SRTP packet, nor is there an authentication tag on the EKTCiphertext that
protects the SPI or length fields (or, for that matter, the message type).
The consequences of this are probably minor, given that an attacker who can
tamper with them could also tamper with the main plaintext, but there is
perhaps potential for causing trouble later in the pipeline, especially
since (as this document admits) there is the possibility of SRTP transforms
that do not provide integrity protection.

The EKT is a group shared symmetric key, with all the usual caveats that
any group member can spoof a message "from" any other group member.
(Reading the group's messages is of course a necessary feature.)
The EKT is furthermore possessed by the central broker in the portrayed
deployment scenario, allowing the broker access to the plaintext of media
if it did not already have such access.

It's probably worth mentioning somewhere what the master salt is used for
so the reader not familiar with the details of RFC 3711 is not left
wondering why we are conveying it.

Section 1

  This document defines Encrypted Key Transport (EKT) for SRTP and
  reduces the amount of external signaling control that is needed in a
  SRTP session with multiple receivers.  EKT securely distributes the
  SRTP master key and other information for each SRTP source.  With
  this method, SRTP entities are free to choose SSRC values as they see
  fit, and to start up new SRTP sources with new SRTP master keys
  within a session without coordinating with other entities via
  external signaling or other external means.

I think you need an explanation and/or reference for previous systems that
required central SSRC allocation (or otherwise why the "free to choose" is
noteworthy here).

  EKT provides a way for an SRTP session participant, to securely
  transport its SRTP master key and current SRTP rollover counter to
  the other participants in the session.  [...]

nit: spurious comma.

                                  This reduces the amount of CPU time
  needed for encryption and can be used for some optimization to media
  sending that use source specific multicast.

nit: I think there's a singular/plural mismatch here.

Section 4

  EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
  Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP
  features duplicate some of the functions of EKT.  Senders MUST NOT
  include MKI when using EKT.  Receivers SHOULD simply ignore any MKI
  field received if EKT is in use.

It feels like we're specifically emphasizing the prohibition on EKT with
MKI, and only saying once that EKT with <From, To> is prohibited.  Is there
a reason to have a stronger prohibition of the one than the other?

Section 4.1

  The EKTField uses the format defined in Figure 1 for the FullEKTField
  and ShortEKTField.

nit: the ShortEKTField is in Figure 2.

    SRTPMasterKeyLength = BYTE
    SRTPMasterKey = 1*256BYTE
    SSRC = 4BYTE; SSRC from RTP
    ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC

nit: is it conventional to all-caps "FOR THE GIVEN"?

  EKTCiphertext: The data that is output from the EKT encryption
  operation, described in Section 4.4.  This field is included in SRTP
  packets when EKT is in use.  The length of EKTCiphertext can be
  larger than the length of the EKTPlaintext that was encrypted.

Doesn't it *need* to be larger in order to provide the stated properties?
(I.e., it "will be larger".)

  SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes.  This
  depends on the cipher suite negotiated for SRTP using SDP Offer/
  Answer [RFC3264] for the SRTP.

This text would seem to forbid using EKT with any mechanism other than SDP
Offer/Answer for central control.

Do we want to say why a Message Type of 1 is not usable?

Section 4.2.2

[Isn't there a step 0 to figure out whether any EKT/extensions are in use?]

  5.  If the SSRC in the EKTPlaintext does not match the SSRC of the
      SRTP packet received, then all the information from this
      EKTPlaintext MUST be discarded and the following steps in this
      list are skipped.

Does this mean I just ignore EKT and attempt to process the SRTP packet
with whatever non-EKT material I have on hand?

      *  Unless the transform specifies other acceptable key lengths,
          the length of the SRTP Master Key MUST be the same as the

This is the first usage of "transform" in this document; perhaps a reminder
to the reader that this is a stock SRTP concept is in order.

          master key length for the SRTP transform in use.  If this is
          not the case, then the receiver MUST abort EKT processing and
          SHOULD discared the whole UDP packet.

nit: The "this" in "if this is not the case" should probably be spelled out
more clearly, as it seems to require both that the master key length is
different from the master key length for the SRTP transform in use and that
the transform specifies other acceptable key lengths.  (Presumably the
master key still needs to match one of those other acceptable key lengths,
though?)

      *  If the length of the SRTP Master Key is less than the master
          key length for the SRTP transform in use, and the transform
          specifies that this length is acceptable, then the SRTP Master
          Key value is used to replace the first bytes in the existing
          master key.  [...]

Do we need to be more clear about what the "existing master key" is?  (Are
there reordering issues where we could operate on a different key than
intended?)  Also, what do I do if the length of the SRTP master key is
larger than the master key length for the transform in use?

Section 4.3

  Section 4.2.1 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

We have multiple types of key floating around; please be clear about which
ones are which.

  only compatible with SRTP transforms that include integrity
  protection.

What's the guidance for when that's not the case?

  When receiving a new EKTKey, implementations need to use the ekt_ttl
  field (see Section 5.2.2) 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 ).  If

Since we knowingly create EKTCiphertexts that are identical, do we count
those as a single encryption or do we count each time we send them?
(I guess Section 4.4 mostly answers this by way of example but a
non-example statement is probably in order.)

                    At this point implementation need to either use the
  call signaling to renegotiate a new session or need to terminate the

nit: "call signaling" seems more SIP-specific than necessary.

  The encryption function returns a ciphertext value C whose length is
  N bytes, where N may be larger than M.  [...]

(same comment about "may be larger" as above)

Section 4.4.2

  An EKTCipher determines how the EKTCiphertext field is written, and
  how it is processed when it is read.  This field is opaque to the
  other aspects of EKT processing.  EKT ciphers are free to use this
  field in any way, but they SHOULD NOT use other EKT or SRTP fields as
  an input.  [...]

Why is this SHOULD NOT instead of MUST NOT?

Section 4.5

Is it worth mentioning (or internally referencing) the 250ms delay before
using the new key?

Section 5.2.1

Given that you're using the DTLS 1.3 handshake structure, why is RFC 5246
the syntax reference?

Section 5.2.2

  If the server did not provide a supported_ekt_ciphers extension in
  its ServerHello, then EKTKey messages MUST NOT be sent by the client
  or the server.

The general text and Figure 4 only show EKTKey being sent by the server.
Is it ever allowed to be sent by the client?

  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 is super-weird to cite draft-ietf-tls-dtls13 and RFC 6347 in adjacent
sentences.

Section 6

  With EKT, each SRTP sender and receiver MUST generate distinct SRTP
  master keys.  [...]

Er, isn't this just senders?

  Note that the inputs of EKT are the same as for SRTP with key-

"inputs" in terms of shared cryptographic material that is fed into the
SRTP (plus EKT) protocol collection?

  sharing: a single key is provided to protect an entire SRTP session.
  However, EKT remains secure even when SSRC values collide.

I think you need to say more about what "secure" is supposed to mean, here.

  The presence of the SSRC in the EKTPlaintext ensures that an attacker
  cannot substitute an EKTCiphertext from one SRTP stream into another
  SRTP stream.

Depends on the attacker; if one of the call participants has the network
positioning to do so, their knowledge of the EKT allows for generating an
EKTCiphertext that matches the SSRC of an arbitrary message.  (I guess
technically that involves modifying and not straight substitution of the
EKTCiphertext.)

  An attacker who tampers with the bits in FullEKTField can prevent the
  intended receiver of that packet from being able to decrypt it.  This
  is a minor denial of service vulnerability.  Similarly the attacker
  could take an old FullEKTField from the same session and attach it to
  the packet.  The FullEKTField would correctly decode and pass
  integrity checks.  However, the key extracted from the FullEKTField ,
  when used to decrypt the SRTP payload, would be wrong and the SRTP
  integrity check would fail.  Note that the FullEKTField only changes
  the decryption key and does not change the encryption key.  None of
  these are considered significant attacks as any attacker that can
  modify the packets in transit and cause the integrity check to fail.

I think this last sentence went a bit funky; presumably it's "any attacker
that can modify the packets in transit can already cause the SRTP integrity
check to fail even in the absence of EKT".

  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 Section 4.3 helps
  mitigate this issue.

I'm not really sure what cases those are supposed to be, since an attacker
can send arbitrary junk and tweak it by a bit each time, and the recipient
has to do the full decryption to validate the integrity IV.

  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

Wouldn't the SSRC check block this particular replay?

  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.

maybe add "by directly modifying the SRTP packet contents"?

  The confidentiality, integrity, and authentication of the EKT cipher
  MUST be at least as strong as the SRTP cipher and at least as strong
  as the DTLS-SRTP ciphers.

EKT doesn't carry anything that's an input to DTLS, so shouldn't this
restriction be that the DTLS cipher must be as stront as the EKT one?

Section 7.1

  All new EKT messages MUST be defined to have a length as second from
  the last element.

"16-bit", right?

section 7.4

  IANA is requested to add ekt_key as a new entry in the "TLS
  HandshakeType Registry" table of the "Transport Layer Security (TLS)
  Parameters" registry with a reference to this specification, a DTLS-
  OK value of "Y", and allocate a value of TBD to for this content
  type.

HandshakeType != content type

[Ballot comment]
I share Benjamin's concern about extensibility.

In 4.4.1:

  The default EKT Cipher is the Advanced Encryption Standard (AES) Key
  Wrap with Padding [RFC5649] algorithm.  It requires a plaintext
  length M that is at least one octet, and it returns a ciphertext with
  a length of N = M + (M mod 8) + 8 octets.

I started looking at RFC 5649. Maybe I was tired and my math was wrong, but I couldn't figure out how you came up with the N value above.
In particular, where is the "+ 8" coming from?

In 6:

  An attacker who tampers with the bits in FullEKTField can prevent the
  intended receiver of that packet from being able to decrypt it.  This
  is a minor denial of service vulnerability.  Similarly the attacker
  could take an old FullEKTField from the same session and attach it to
  the packet.  The FullEKTField would correctly decode and pass
  integrity checks.  However, the key extracted from the FullEKTField ,
  when used to decrypt the SRTP payload, would be wrong and the SRTP
  integrity check would fail.  Note that the FullEKTField only changes
  the decryption key and does not change the encryption key.  None of
  these are considered significant attacks as any attacker that can
  modify the packets in transit and cause the integrity check to fail.

The last sentence seems to be incomplete. Did you mean "can" instead of the last "and"?

[Ballot discuss]
I'm adding a process discuss to hold things until we get clarity around the IANA expert reviews.

I know Benjamin mentioned this in his DISCUSS; I am duplicating it here in case we clear up the rest of Benjamin's discuss points prior to the IANA questions.

[Ballot discuss]
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?

I'll also hold a discuss for the IANA NOT OK (I noticed the need for more
columns for TLS extension type, at least, and there seems to be more in
their review).

Please state clearly what the scope of an SPI value (and its binding to
EKTKey and  other parameters) is; e.g., that it is only defined within a
given communications session.

Section 4.2.1

  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.

What channel is the "sending any new key" to occur on?  The most
straightforward reading would be in the FullEKTField, but that does not
seem to make much sense.  (Also, is the "any new key" an SRTP master key or
an EKTKey?)

Section 5's one-paragraph intro doesn't really paint a clear picture for me
of why/which DTLS connections are "secure" in a way that the central media
distribution is not.  From reading the whole doc, my perception is that
basically this scheme is useful in cases when you have a central hub for
DTLS negotiation that's trusted to have access to media plaintext, plus a
mesh of SRTP streams (whether centrally mediated or directly connected),
and that it's not appropriate when the  central hub is not trusted with
media access or when there is not a single DTLS party that can distribute
the EKT to all (other) participants).  Could we get some clear explanation
of where this technique is and is not expected to be utilized?

Section 5.5.2 has:

  Note: To be clear, EKT can be used with versions of DTLS prior to
  1.3.  The only difference is that in a pre-1.3 TLS stacks will not
  have built-in support for generating and processing Ack messages.

You need to be more clear about the Ack being needed even when pre-1.3 is
in use (which would seem to make DLTS 1.3 a normative reference).
(See also the COMMENT about citing both DTLS 1.2 and 1.3.)

[Ballot comment]
There is no cryptographic binding between the EKTCiphertext and the main
SRTP packet, nor is there an authentication tag on the EKTCiphertext that
protects the SPI or length fields (or, for that matter, the message type).
The consequences of this are probably minor, given that an attacker who can
tamper with them could also tamper with the main plaintext, but there is
perhaps potential for causing trouble later in the pipeline, especially
since (as this document admits) there is the possibility of SRTP transforms
that do not provide integrity protection.

The EKT is a group shared symmetric key, with all the usual caveats that
any group member can spoof a message "from" any other group member.
(Reading the group's messages is of course a necessary feature.)
The EKT is furthermore possessed by the central broker in the portrayed
deployment scenario, allowing the broker access to the plaintext of media
if it did not already have such access.

It's probably worth mentioning somewhere what the master salt is used for
so the reader not familiar with the details of RFC 3711 is not left
wondering why we are conveying it.

Section 1

  This document defines Encrypted Key Transport (EKT) for SRTP and
  reduces the amount of external signaling control that is needed in a
  SRTP session with multiple receivers.  EKT securely distributes the
  SRTP master key and other information for each SRTP source.  With
  this method, SRTP entities are free to choose SSRC values as they see
  fit, and to start up new SRTP sources with new SRTP master keys
  within a session without coordinating with other entities via
  external signaling or other external means.

I think you need an explanation and/or reference for previous systems that
required central SSRC allocation (or otherwise why the "free to choose" is
noteworthy here).

  EKT provides a way for an SRTP session participant, to securely
  transport its SRTP master key and current SRTP rollover counter to
  the other participants in the session.  [...]

nit: spurious comma.

                                  This reduces the amount of CPU time
  needed for encryption and can be used for some optimization to media
  sending that use source specific multicast.

nit: I think there's a singular/plural mismatch here.

Section 4

  EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key
  Identifier) or with SRTP's <From, To> [RFC3711], as those SRTP
  features duplicate some of the functions of EKT.  Senders MUST NOT
  include MKI when using EKT.  Receivers SHOULD simply ignore any MKI
  field received if EKT is in use.

It feels like we're specifically emphasizing the prohibition on EKT with
MKI, and only saying once that EKT with <From, To> is prohibited.  Is there
a reason to have a stronger prohibition of the one than the other?

Section 4.1

  The EKTField uses the format defined in Figure 1 for the FullEKTField
  and ShortEKTField.

nit: the ShortEKTField is in Figure 2.

    SRTPMasterKeyLength = BYTE
    SRTPMasterKey = 1*256BYTE
    SSRC = 4BYTE; SSRC from RTP
    ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC

nit: is it conventional to all-caps "FOR THE GIVEN"?

  EKTCiphertext: The data that is output from the EKT encryption
  operation, described in Section 4.4.  This field is included in SRTP
  packets when EKT is in use.  The length of EKTCiphertext can be
  larger than the length of the EKTPlaintext that was encrypted.

Doesn't it *need* to be larger in order to provide the stated properties?
(I.e., it "will be larger".)

  SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes.  This
  depends on the cipher suite negotiated for SRTP using SDP Offer/
  Answer [RFC3264] for the SRTP.

This text would seem to forbid using EKT with any mechanism other than SDP
Offer/Answer for central control.

Do we want to say why a Message Type of 1 is not usable?

Section 4.2.2

[Isn't there a step 0 to figure out whether any EKT/extensions are in use?]

  5.  If the SSRC in the EKTPlaintext does not match the SSRC of the
      SRTP packet received, then all the information from this
      EKTPlaintext MUST be discarded and the following steps in this
      list are skipped.

Does this mean I just ignore EKT and attempt to process the SRTP packet
with whatever non-EKT material I have on hand?

      *  Unless the transform specifies other acceptable key lengths,
          the length of the SRTP Master Key MUST be the same as the

This is the first usage of "transform" in this document; perhaps a reminder
to the reader that this is a stock SRTP concept is in order.

          master key length for the SRTP transform in use.  If this is
          not the case, then the receiver MUST abort EKT processing and
          SHOULD discared the whole UDP packet.

nit: The "this" in "if this is not the case" should probably be spelled out
more clearly, as it seems to require both that the master key length is
different from the master key length for the SRTP transform in use and that
the transform specifies other acceptable key lengths.  (Presumably the
master key still needs to match one of those other acceptable key lengths,
though?)

      *  If the length of the SRTP Master Key is less than the master
          key length for the SRTP transform in use, and the transform
          specifies that this length is acceptable, then the SRTP Master
          Key value is used to replace the first bytes in the existing
          master key.  [...]

Do we need to be more clear about what the "existing master key" is?  (Are
there reordering issues where we could operate on a different key than
intended?)  Also, what do I do if the length of the SRTP master key is
larger than the master key length for the transform in use?

Section 4.3

  Section 4.2.1 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

We have multiple types of key floating around; please be clear about which
ones are which.

  only compatible with SRTP transforms that include integrity
  protection.

What's the guidance for when that's not the case?

  When receiving a new EKTKey, implementations need to use the ekt_ttl
  field (see Section 5.2.2) 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 ).  If

Since we knowingly create EKTCiphertexts that are identical, do we count
those as a single encryption or do we count each time we send them?
(I guess Section 4.4 mostly answers this by way of example but a
non-example statement is probably in order.)

                    At this point implementation need to either use the
  call signaling to renegotiate a new session or need to terminate the

nit: "call signaling" seems more SIP-specific than necessary.

  The encryption function returns a ciphertext value C whose length is
  N bytes, where N may be larger than M.  [...]

(same comment about "may be larger" as above)

Section 4.4.2

  An EKTCipher determines how the EKTCiphertext field is written, and
  how it is processed when it is read.  This field is opaque to the
  other aspects of EKT processing.  EKT ciphers are free to use this
  field in any way, but they SHOULD NOT use other EKT or SRTP fields as
  an input.  [...]

Why is this SHOULD NOT instead of MUST NOT?

Section 4.5

Is it worth mentioning (or internally referencing) the 250ms delay before
using the new key?

Section 5.2.1

Given that you're using the DTLS 1.3 handshake structure, why is RFC 5246
the syntax reference?

Section 5.2.2

  If the server did not provide a supported_ekt_ciphers extension in
  its ServerHello, then EKTKey messages MUST NOT be sent by the client
  or the server.

The general text and Figure 4 only show EKTKey being sent by the server.
Is it ever allowed to be sent by the client?

  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 is super-weird to cite draft-ietf-tls-dtls13 and RFC 6347 in adjacent
sentences.

Section 6

  With EKT, each SRTP sender and receiver MUST generate distinct SRTP
  master keys.  [...]

Er, isn't this just senders?

  Note that the inputs of EKT are the same as for SRTP with key-

"inputs" in terms of shared cryptographic material that is fed into the
SRTP (plus EKT) protocol collection?

  sharing: a single key is provided to protect an entire SRTP session.
  However, EKT remains secure even when SSRC values collide.

I think you need to say more about what "secure" is supposed to mean, here.

  The presence of the SSRC in the EKTPlaintext ensures that an attacker
  cannot substitute an EKTCiphertext from one SRTP stream into another
  SRTP stream.

Depends on the attacker; if one of the call participants has the network
positioning to do so, their knowledge of the EKT allows for generating an
EKTCiphertext that matches the SSRC of an arbitrary message.  (I guess
technically that involves modifying and not straight substitution of the
EKTCiphertext.)

  An attacker who tampers with the bits in FullEKTField can prevent the
  intended receiver of that packet from being able to decrypt it.  This
  is a minor denial of service vulnerability.  Similarly the attacker
  could take an old FullEKTField from the same session and attach it to
  the packet.  The FullEKTField would correctly decode and pass
  integrity checks.  However, the key extracted from the FullEKTField ,
  when used to decrypt the SRTP payload, would be wrong and the SRTP
  integrity check would fail.  Note that the FullEKTField only changes
  the decryption key and does not change the encryption key.  None of
  these are considered significant attacks as any attacker that can
  modify the packets in transit and cause the integrity check to fail.

I think this last sentence went a bit funky; presumably it's "any attacker
that can modify the packets in transit can already cause the SRTP integrity
check to fail even in the absence of EKT".

  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 Section 4.3 helps
  mitigate this issue.

I'm not really sure what cases those are supposed to be, since an attacker
can send arbitrary junk and tweak it by a bit each time, and the recipient
has to do the full decryption to validate the integrity IV.

  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

Wouldn't the SSRC check block this particular replay?

  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.

maybe add "by directly modifying the SRTP packet contents"?

  The confidentiality, integrity, and authentication of the EKT cipher
  MUST be at least as strong as the SRTP cipher and at least as strong
  as the DTLS-SRTP ciphers.

EKT doesn't carry anything that's an input to DTLS, so shouldn't this
restriction be that the DTLS cipher must be as stront as the EKT one?

Section 7.1

  All new EKT messages MUST be defined to have a length as second from
  the last element.

"16-bit", right?

section 7.4

  IANA is requested to add ekt_key as a new entry in the "TLS
  HandshakeType Registry" table of the "Transport Layer Security (TLS)
  Parameters" registry with a reference to this specification, a DTLS-
  OK value of "Y", and allocate a value of TBD to for this content
  type.

HandshakeType != content type

[Ballot discuss]
The document is generally quite readable, which is great. But I have a few small issues I would like to get clarification on before recommending approval of this document:

In 4.1:

  Message Type: The last byte is used to indicate the type of the
  EKTField.  This MUST be 2 for the FullEKTField format and 0 in
  ShortEKTField format.  Values less than 64 are mandatory to
  understand while other values are optional to understand.

I thought I knew what this meant when I read it, and then I saw this:

  A receiver
  SHOULD discard the whole EKTField if it contains any message type
  value that is less than 64 and that is not understood.

"SHOULD discard ... EKTField" makes this field NOT mandatory. (If you said "SHOULD discard the whole packet", that would have been different.)
Also, how "discard" different from the following sentence suggesting "ignore"?
I think you have some inconsistencies/terminology problem here!

  Message type
  values that are 64 or greater but not implemented or understood can
  simply be ignored.

[Ballot comment]
I share Benjamin's concern about extensibility.

General:

Mixture of normative TLS 1.2 and TLS 1.3 references is confusing in the document. There is a note later on explaining that either can be used, but it would be better for readers to see this note earlier in the document.

In 4.1:

  EKTMsgLength = 2BYTE;

and similarly:

  SPI = 2BYTE

The document doesn't seem to say whether or not this is in network byte order.

In 4.2.1:

  2.  The EKTPlaintext field is computed from the SRTP Master Key,
      SSRC, and ROC fields, as shown in Section 4.1.  The ROC, SRTP
      Master Key, and SSRC used in EKT processing SHOULD be the same as
      the one used in the SRTP processing.

When can they be different? I.e. why is this not a MUST?

  The computed value of the FullEKTField is written into the SRTP
  packet.

I think this might be misleading. Do you just mean appended to the end of the SRTP packet after encrypted data?
If yes, please say so to avoid confusion with writing it into encrypted data before encryption.

In 4.3:

  When receiving a new EKTKey, implementations need to use the ekt_ttl
  field (see Section 5.2.2) 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 ).

Missing reference after "see" here.

In 4.4.1:

  The default EKT Cipher is the Advanced Encryption Standard (AES) Key
  Wrap with Padding [RFC5649] algorithm.  It requires a plaintext
  length M that is at least one octet, and it returns a ciphertext with
  a length of N = M + (M mod 8) + 8 octets.

I started looking at RFC 5649. Maybe I was tired and my math was wrong, but I couldn't figure out how you came up with the N value above.
In particular, where is the "+ 8" coming from?

In 4.7:

  New sender:
      A new sender SHOULD send a packet containing the FullEKTField as
      soon as possible, always before or coincident with sending its
      initial SRTP packet.  To accommodate packet loss, it is
      RECOMMENDED that three consecutive packets contain the
      FullEKTField be transmitted.  If the sender does not send a
      FullEKTField in its initial packets and receivers have not
      otherwise been provisioned with a decryption key, then decryption
      will fail and SRTP packets will be dropped until the the receives

Nit: duplicated "the".

      a FullEKTField from the sender.

In 6:

  An attacker who tampers with the bits in FullEKTField can prevent the
  intended receiver of that packet from being able to decrypt it.  This
  is a minor denial of service vulnerability.  Similarly the attacker
  could take an old FullEKTField from the same session and attach it to
  the packet.  The FullEKTField would correctly decode and pass
  integrity checks.  However, the key extracted from the FullEKTField ,
  when used to decrypt the SRTP payload, would be wrong and the SRTP
  integrity check would fail.  Note that the FullEKTField only changes
  the decryption key and does not change the encryption key.  None of
  these are considered significant attacks as any attacker that can
  modify the packets in transit and cause the integrity check to fail.

The last sentence seems to be incomplete. Did you mean "can" instead of the last "end"?

[Ballot comment]

Thanks to the work that everyone has put in on getting an EKT mechanism
specified and finalized. I have a handful of comments that I would like to see
considered prior to publication of the document.

---------------------------------------------------------------------------

§1:

>  EKT provides a way for an SRTP session participant, to securely
>  transport its SRTP master key and current SRTP rollover counter to
>  the other participants in the session.

Nit: "...participant to securely..."

---------------------------------------------------------------------------

§4.1:

>  EKTMsgTypeExtension = %x03-FF

Shouldn't this be "%x01 / %x03-ff" ?

>  SRTPMasterKeyLength = BYTE
>  SRTPMasterKey = 1*256BYTE

I think this either needs to be "1*255BYTE", or we need text that explicitly
indicates that an SRTPMasterKeyLength value of 0x00 means "256 bytes." Probably
the former.

I think this is even further constrained by the fact that EKTCiphertext is
limited to 256 bytes, and contains the SRTPMasterKeyLength, SRTPMasterKey,
SSRC, and ROC (and is not compressed) -- which means the SRTPMasterKeyLength
can't be more than (256 - 1 - 4 - 4 =) 247 bytes. So perhaps "1*247BYTE" is
more appropriate?

---------------------------------------------------------------------------

§4.2.1:

>  The creation of the EKTField MUST precede the normal SRTP
>  packet processing.

Why? This seems unnecessary and unnecessarily complicated. If the order of
operations has an impact on the bits on the wire (I don't see how it does?),
then please include some explanatory text here that clarifies the reason for
this constraint.

---------------------------------------------------------------------------

§4.2.1:

>  When a packet is sent with the ShortEKTField, the ShortEKFField is
>  simply appended to the packet.

Nit: s/ShortEKFField/ShortEKTField/

---------------------------------------------------------------------------

§4.2.1:

>  5.  If the SSRC in the EKTPlaintext does not match the SSRC of the
>      SRTP packet received, then all the information from this
>      EKTPlaintext MUST be discarded and the following steps in this
>      list are skipped.

I can see implementors easily interpreting this as requiring them to discard
the RTP payload as well. If that's not the intention (I don't think it is),
consider adding text like "The FullEKTField is removed from the packet then
normal SRTP or SRTCP processing occurs."

---------------------------------------------------------------------------

§4.3:

>  Section 4.2.1 recommends that SRTP senders continue using an old key
>  for some time after sending a new key in an EKT tag.

This is the first appearance of the phrase "EKT tag," which never seems to be
properly defined. I presume this is meant to be the combination of the EKT
Ciphertext and the SPI?

In any case, please clearly define this term somewhere, preferably before using
it the first time.

---------------------------------------------------------------------------

§4.3:

>  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 ).

The parenthetical phrase appears to be missing something here.

>  If
>  either of these limits are exceeded, the key can no longer be used

Nit: "...either... is exceeded..."

>  for encryption.  At this point implementation need to either use the

Nit: "...implementations need..."

---------------------------------------------------------------------------

§4.5:

>  If a source has its EKTKey changed by the key management, it MUST
>  also change its SRTP master key

I suppose it's not terribly important for interop, but the implication that this
change takes place immediately seems to contradict the 250 ms period specified
in §4.2.1. Perhaps a few words here about how these two normative statements
are intended to interact would save implementors a bit of grief.

---------------------------------------------------------------------------

§4.6:

>  This document defines the use of EKT with SRTP.  Its use with SRTCP
>  would be similar, but is reserved for a future specification.

After reading this far, I was quite surprised to find this qualification. If
this is the intention for this document, please adjust the rest of the text to
match. Some examples follow.

>  The following shows the syntax of the EKTField expressed in ABNF
>  [RFC5234].  The EKTField is added to the end of an SRTP or SRTCP
>  packet.
-----
>  Rollover Counter (ROC): On the sender side, this is set to the
>  current value of the SRTP rollover counter in the SRTP/SRTCP context
>  associated with the SSRC in the SRTP or SRTCP packet.
-----
>  1.  The final byte is checked to determine which EKT format is in
>      use.  When an SRTP or SRTCP packet contains a ShortEKTField, the
>      ShortEKTField is removed from the packet then normal SRTP or
>      SRTCP processing occurs.
-----
>      The reason for
>      using the last byte of the packet to indicate the type is that
>      the length of the SRTP or SRTCP part is not known until the
>      decryption has occurred.
-----
>  7.  At this point, EKT processing has successfully completed, and the
>      normal SRTP or SRTCP processing takes place.
-----
>  This allows
>  those peers to process EKT keying material in SRTP (or SRTCP) and
>  retrieve the embedded SRTP keying material.

---------------------------------------------------------------------------

§4.7:

>    To accommodate packet loss, it is
>    RECOMMENDED that three consecutive packets contain the
>    FullEKTField be transmitted.

Nit: "...containing..." (alternately, remove "be transmitted" -- both make a
grammatically correct sentance)

More substantially -- under "New sender:", I'm a little surprised that there
isn't any mention of other senders re-keying in response to a new sender
joining. In the vast majority of conferences, when a sender joins, that same
entity generally will also be a receiver. It seems this should trigger other
senders to include the key in their next packet.

---------------------------------------------------------------------------

§4.7:

>  Rekey:
>    By sending EKT tag over SRTP, the rekeying event shares fate with
>    the SRTP packets protected with that new SRTP master key.

Is this actually true? Going back to the 250 ms period specified in §4.2.1, it
seems that the master key is sent out in packets pretty far removed from those
it actually protects.

Between this and the inconsistency I mention in §4.5 above, this increasingly
feels like maybe there were two different ways of reasoning about the timing
of sending a master key versus the timing of actually using it. Does the text
in §4.2.1 perhaps represent an outdated notion of how this is intended to
work?

---------------------------------------------------------------------------

§4.7:

>    If sending audio and video, the RECOMMENDED
>    frequency is the same as the rate of intra coded video frames.  If
>    only sending audio, the RECOMMENDED frequency is every 100ms.

Is this "100ms" correct?  Assuming, say, the use of Opus at voice quality with
20 ms packets, this is taking packets on the order of 40 bytes in length and
tacking on something like 20 to 30 bytes to every fifth packet. That's an
increase in overall stream size on the order of roughly 15% to 20%.

At the same time, when using real-time video, intra frames are going to happen
roughly every 500 ms to 1500 ms. If a cadence on that order is okay for
audiovisual streams, I have to imagine it's okay for audio streams.

So, to clarify: is this "100ms" a typo for "1000 ms"?

---------------------------------------------------------------------------

§7.2:

>                  +----------+-------+---------------+
>                  | Name    | Value | Specification |
>                  +----------+-------+---------------+
>                  | AESKW128 |    1 | RFCAAAA      |
>                  | AESKW256 |    2 | RFCAAAA      |
>                  | Reserved |  255 | RFCAAAA      |
>                  +----------+-------+---------------+
>
>                        Table 3: EKT Cipher Types

Section 5.2.1 reserves "0" as well. I suspect we want to replicate that
reservation in this table.

[Ballot 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?

[Ballot comment]
Just a quick clarification question:
Sec 4.2.1: "  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."
I assume that 250ms is selected under the assumption that longer RTTs are a problem for interactive communication anyway? Or where does this value come from?

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3741

IMPORTANT
S 4.4.1.
>      FullEKTField is retransmitted 3 times, that only counts as 1
>      encryption.
> 
>      Security requirements for EKT ciphers are discussed in Section 6.
> 
>  4.4.1.  Ciphers

How do I know which cipher is in use? Is it attached to EKTKey?

S 5.2.2.
>      Note: To be clear, EKT can be used with versions of DTLS prior to
>      1.3.  The only difference is that in a pre-1.3 TLS stacks will not
>      have built-in support for generating and processing Ack messages.
> 
>      If an EKTKey message is received that cannot be processed, then the
>      recipient MUST respond with an appropriate DTLS alert.

How important is it that you (a) be able to change EKTKeys and (b) be
able to work with DTLS < 1.3? Because if the answer to these is "no",
then you can just send EKTKeys in EncryptedExtensions.

S 6.
>      With EKT, each SRTP sender and receiver MUST generate distinct SRTP
>      master keys.  This property avoids any security concern over the re-
>      use of keys, by empowering the SRTP layer to create keys on demand.
>      Note that the inputs of EKT are the same as for SRTP with key-
>      sharing: a single key is provided to protect an entire SRTP session.
>      However, EKT remains secure even when SSRC values collide.

How am I supposed to decrypt in case I don't have a FullEKTField? Am I
supposed to use the IP address.

S 6.
>      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.

Why don't you add an epoch so that you can't roll back?

COMMENTS
S 4.1.
>        :                                                              :
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |  Security Parameter Index    | Length                        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |0 0 0 0 0 0 1 0|
>        +-+-+-+-+-+-+-+-+

This encoding seems suboptimal, in that you burn an extra byte for
every FullEKTField. Given that:

1. You are only defining two types
2. It seems unlikely that there will ever be an EKTCiphertext longer
than 128 bits.

I would suggest the following encoding:

- The first bit of the last byte indicates whether this is
FullEKTField or <Something else.>. If it's FullEKTField, the rest is
used for length. Otherwise, the rest is used for type.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-perc-srtp-ekt-diet-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, a new registry is to be created called the EKT Messages Types registry. The new registry will be located on the Real-Time Transport Protocol (RTP) Parameters registry page located at:

https://www.iana.org/assignments/rtp-parameters/

The new registry will be maintained via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+--------------+-------+---------------+
| Message Type | Value | Reference |
+--------------+-------+---------------+
| Short | 0 | [ RFC-to-be ] |
| Full | 2 | [ RFC-to-be ] |
| Reserved | 63 | [ RFC-to-be ] |
| Reserved | 255 | [ RFC-to-be ] |
+--------------+-------+---------------+

IANA Question --> Are the values 1, 3-62, and 64-254 unassigned and available for future assignment? Is 255 the maximal value in the registry?

Second, a new registry is to be created called the EKT Ciphers registry. The new registry will be located on the Real-Time Transport Protocol (RTP) Parameters registry page located at:

https://www.iana.org/assignments/rtp-parameters/

The new registry will be maintained via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+----------+-------+---------------+
| Name | Value | Specification |
+----------+-------+---------------+
| AESKW128 | 1 | [ RFC-to-be ] |
| AESKW256 | 2 | [ RFC-to-be ] |
| Reserved | 255 | [ RFC-to-be ] |
+----------+-------+---------------+

IANA Question --> Are the values 0, and 3-254 unassigned and available for future assignment? Is 255 the maximal value in the registry?

Third, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registr4y page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a single, new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Extension Name: supported_ekt_ciphers
TLS 1.3:
Recommended:
Reference: [ RFC-to-be ]

IANA Question --> What should the values be for the entries "TLS 1.3" and "Recommended" for this new registration?

Because this registry requires Expert Review [RFC 8126] for registration, the IESG-designated experts for the TLS ExtensionType Values registry have asked that you send a review request to the mailing list. Expert review should be completed before your document can be approved for publication as an RFC.

Fourth, in the TLS HandshakeType registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

a single, new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Description: ekt_key
DTLS-OK:
Reference: [ RFC-to-be ]

IANA Question --> What should the value be for the entry "DTLS-OK" for this new registration?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-11-01):

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: ben@nostrum.com, suhasietf@gmail.com, perc@ietf.org, draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar <suhasietf@gmail.com>, perc-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-perc-srtp-ekt-diet-09.txt> (Encrypted Key Transport for DTLS and Secure RTP) to Proposed Standard

The IESG has received a request from the Privacy Enhanced RTP Conferencing
WG (perc) to consider the following document: - 'Encrypted Key Transport for
DTLS and Secure RTP'
  <draft-ietf-perc-srtp-ekt-diet-09.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-11-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

  Encrypted Key Transport (EKT) is an extension to DTLS (Datagram
  Transport Layer Security) and Secure Real-time Transport Protocol
  (SRTP) that provides for the secure transport of SRTP master keys,
  rollover counters, and other information within SRTP.  This facility
  enables SRTP for decentralized conferences by distributing a common
  key to all of the conference endpoints.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3231/

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.

*** Substantive Comments: ***

§3: Is there a reason not to use the RFC 8174 boilerplate? There are at least a few instances of lowercase keywords in places that don’t seem intended as normative.

§4.2.1, first paragraph: Is there never a situation where you send neither version?  Also, did I miss a description of the purpose and semantics for ShortEKTField, other than “send it when you don’t send the full version”?

§4.2.2, step 3: "If the EKT decryption operation returns an authentication failure, then the packet processing stops.”

... and then what?

- Step 6: "This applies in transforms such as [ I-D.ietf-perc-double] for replacing just half the key, but SHOULD return a processing error otherwise.”

I don’t understand that sentence. Is the point to say that using a “too short” key to replace part of the old key is only valid for perc-double or similar transforms, and receiving one in other contexts is an error?

- Next Sentence: "Outbound packets SHOULD continue to use the old SRTP Master Key for 250 ms after” Does that imply a normative requirement for recipients to keep old keys around for at least that long? There’s currently an implementation suggestion about that, but it doesn’t use MUST or SHOULD.
(Editorial: The sentence seems to belong in the “outbound” section, not the “inbound” section.)

§4.3:

- “ 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 .”

Are we really talking about the recipient? How would the recipient know that the key has not changed without processing the ciphertext value? (Also, the sentence is unfinished--maybe the answer would be clear if the rest of the sentence came out of hiding :-) )

- “ 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.”

See comment to §4.2.2, step 6. “may want” seems weak given that the sender SHOULD keep using the old key for a period of time.

§4.7: “A new sender SHOULD send a packet containing the FullEKTField as soon as possible...”

Why not MUST? Would it ever make sense not to do this? It seems like the mechanism doesn’t work very well otherwise.

§6, first paragraph: “or other” - what other?

- paragraph 8: “ An endpoint MUST NOT encrypt more than T different FullEKTField values using the same EKTKey.”

Is there a reciprocal requirement for decryption?

- last paragraph: “...SHOULD be limited using the ekt_ttl”

Why not MUST?

§7.3: Should this cite RFC 5246 instead of RFC 4366?

*** Editorial Comments: ***

§2: “...each endpoint picks there own SRTP master key...:
s/their/its

§4.1, first paragraph: Please reference figures by number. I can imagine some future RFC rendering failing to  maintain the relative positions.  (This occurs a few times throughout the document.)

§4.2.2, step 3:
Should "The EKTCiphertext authentication is checked and is decrypted” be something like “
The EKTCiphertext field authentication is checked and its contents decrypted” I assume you don’t mean to say its authentication is decrypted.

Also, there’s a number of occurrences of “The [fieldname]...” that should probably say “The [fieldname] field...”

- Step 6: s/crypto/cryptographic

- Step 7: is the replay protection part relevant to the step?

§4.3, third paragraph: This is the first mention of ekt_ttl. It would help to have a brief explanation or at least a forward reference.

§4.6: s/ “other specification” / “another specification” ; or “other specifications”

§4.7, third paragraph: Both occurrences of “which” need preceding commas.

§5.2, paragraph after figure 4: “ ... the extensions defined in this session allows the DTLS server...”
Defined in this “session” or this “section”?

§, paragraph 7: “... causing the receiving system will decrypt...”
s/will/to

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-perc-srtp-ekt-diet is targeted at the Standards track,
and this write­up is for Proposed Standard. This is reflected on the title page
and in the data tracker.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines extensions to DTLS-SRTP and SRTP for securely
Transmitting SRTP master keys and related information in the
Media path for decentralized multimedia conferences

Working Group Summary
The current version of the specification is a streamlined
version of draft-ietf-avtcore-srtp-ekt to cater to PERC WG
use cases. The AVTCore version of the this draft was
extensively reviewed prior to producing this version of
the draft in PERC WG. The version adopted by the PERC WG
has been discussed several times and reviewed both internally
and by security area personnel (Russ Housley, Sean Turner)

This document in general has gotten strong support from
the working group as the work that needs to be done.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

An early draft of EKT was implemented in many of
Cisco telepresence products and has been widely shipped and used.
libsrtp, a widely used SRTP library in commercial and open source
SIP  and Webrtc products, has a branch with the implementation
for EKT. A branch of Firefox has the relevant integration for
performing DTLS-SRTP and EKTKey setup procedures as part
of NSS library.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

The document shepherd is Suhas Nandakumar;
the responsible Area Director is Ben Campbell.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This document has been reviewed and discussed several times with in
the WG. It has been reviewed by personnel from Security Area.
Special thanks to Russ Housley and Sean Turner for their detailed
reviews.)

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I do not have any concerns about the working group reviews to date.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Another round of Security review and TLS WG personnel is welcomed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns that I am aware of.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
There was an IPR filed for the original author version of this draft
back in 2006 https://datatracker.ietf.org/ipr/707/.  Cisco has filed the
same IPR  on the current version here: https://datatracker.ietf.org/ipr/3231/

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

It's solid

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No threats of appeal or otherwise.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

There were couple of warnings in the draft-ietf-perc-srtp-ekt-diet-08.txt
and authors have been notified of the same

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not present the need for these reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

Not applicable.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no requests for downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document requests an update couple of existing registries.
- RTP parameters registry needs to be updated to include new tables
for "EKT Message Types" and "EKT Ciphers"

- Transport Layer Security (TLS) Extensions registry needs to be updated
to defined "supported_ekt_ciphers" as new extension

-  TLS HandshakeType Registry needs to be updated to add "ekt_key" as
a new handshake type.

The IANA requests is appropriately defined in the document.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document does not request new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ABNF content in the document was validated with
https://tools.ietf.org/tools/bap/abnf.cgi