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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 17 July 2019 20:12 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BFE120071; Wed, 17 Jul 2019 13:12:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar <suhasietf@gmail.com>, perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156339433620.25783.14611652111059201524.idtracker@ietfa.amsl.com>
Date: Wed, 17 Jul 2019 13:12:16 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/o72EN-5hKXQAZubcTqGAkDKcOXY>
Subject: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-srtp-ekt-diet-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jul 2019 20:12:16 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.


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