[Perc] Review of draft-ietf-perc-srtp-ekt-diet-07

[Jonathan Lennox <[e-mail]>]

Hi - I reviewed ekt-diet.  Sorry for this not coming in until the meeting.

Substantive:

   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 should say using DTLS/SRTP.  There are other references to Offer/Answer scattered around the descriptions as well.


  A receiver
   SHOULD discard the whole EKTField if it contains any message type
   value that is less than 64 and that is not understood.  Message type
   values that are 64 or greater but not implemented or understood can
   simply be ignored.

What is the difference between discarding and ignoring?  Is there an implication that a packet can carry more than one EKTField? How does this affect the treatment of the rest of the SRTP packet?

At any given time, each SRTP/SRTCP source has associated with it a
   single EKT parameter set
In RFC 7656 terminology (which we’re trying to get all RTP-related documents to use), this should be a stream, not a source.  Source is a higher-level concept.

Generally, this document should be checked for RFC 7656 alignment, and either brought into alignment or (if you must) have the differences called out.

There may be other EKT parameter sets that are used by other
   SRTP/SRTCP sources in the same session, including other SRTP/SRTCP
   sources on the same endpoint (e.g., one endpoint with voice and video
   might have two EKT parameter sets, or there might be multiple video
   sources on an endpoint each with their own EKT parameter set).
Is it valid for multiple sources (streams) from the same endpoint to share an EKT parameter set if the sender wishes? Or must every source have a unique parameter set?

I think the latter is the case (because the parameter set includes SSRC and ROC) but it’s not clear.

  The ROC, SRTP
       Master Key, and SSRC used in EKT processing SHOULD be the same as
       the one used in the SRTP processing.
Why is this only SHOULD?  When would a sender want them to be different?  Especially since 4.2.2 Step 5 says the values MUST be discarded if the SSRCs don’t match.

       *  Note: the value of the EKTCiphertext field is identical in
          successive packets protected by the same EKTKey and SRTP
          master key.  This value MAY be cached by an SRTP sender to
          minimize computational effort.
This is true except when the RTP sequence number rolls over, causing the ROC to increment.  (This is explained later, but should be said here as well.)

       If the SRTP Master
       Key recovered from the EKTPlaintext is shorter than needed by
       SRTP transform in use, then the bytes received replace the first
       bytes in the existing key but the other bytes after that remain
       the same as the old key.  This allows for replacing just half the
       key for transforms such as [I-D.ietf-perc-double].
This feels unnecessarily, and dangerously, over-general to me.  I’d suggest that specific transforms MAY allow specific sets of key bytes to be replaced, but the default is that all bytes MUST be replaced.

Note that if the same
   FullEKTField is retransmitted 3 times, that only counts as 1
   encryption.

Is “3” a special value here, or do you mean “multiple”?

   EKT SHOULD be used over SRTP, and other specification MAY define how
   to use it over SRTCP.  SRTP is preferred because it shares fate with
   transmitted media, because SRTP rekeying can occur without concern
   for RTCP transmission limits, and to avoid SRTCP compound packets
   with RTP translators and mixers.

Does this mean that SRTCP packets always carry just a short EKT field, or do they not carry an EKT suffix at all?

Editorial:

1.
Real-time Transport Protocol (RTP) is designed 
Should be *The* Real-time Transport Protocol

2.
   EKT does not control the manner in which the SSRC is generated; it is
   only concerned with their secure transport.
Number agreement: “the SSRC” vs. “their”.  Probably the former should be “the manner in which SSRCs are generated.”

4.1
 EKTMsgLength: All EKT message other that ShortEKTField
“All EKT messages”; “than”

4.2.1:

   When a packet is sent with the Short EKT Field, the ShortEKFField is
   simply appended to the packet.
“ShortEKTField”

4.2.2:
   2.  The Security Parameter Index (SPI) field is used to find which
       EKT parameter set to be used when processing the packet.
“which EKT parameter set is to be used”


4.3:

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

“Implementations need”; “to renegotiate”.