Encrypted Key Transport for DTLS and Secure RTP
draft-ietf-perc-srtp-ekt-diet-09

Summary: Has 2 DISCUSSes. Needs 3 more YES or NO OBJECTION positions to pass.

(Ben Campbell) (was Yes) Discuss

Discuss (2019-02-21)
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.

Benjamin Kaduk Discuss

Discuss (2019-02-20)
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.)
Comment (2019-02-20)
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

Alexey Melnikov Discuss

Discuss (2019-02-20)
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.
Comment (2019-02-20)
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"?

Adam Roach Yes

Comment (2019-02-19)
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.

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2019-02-20)
I think I-D.ietf-tls-dtls13 needs to be a normative reference.

(Spencer Dawkins) No Objection

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Comment (2019-02-19)
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?

(Eric Rescorla) No Objection

Comment (2019-02-16)
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.

Alvaro Retana No Objection

Martin Vigoureux No Objection

Ignas Bagdonas No Record

Roman Danyliw No Record

Warren Kumari No Record

Barry Leiba No Record

Éric Vyncke No Record

Magnus Westerlund No Record