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

Richard Barnes <rlb@ipv.sx> Fri, 02 August 2019 18:48 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42011207DE for <perc@ietfa.amsl.com>; Fri, 2 Aug 2019 11:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Shm_ILyCGyZO for <perc@ietfa.amsl.com>; Fri, 2 Aug 2019 11:48:56 -0700 (PDT)
Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458F91207E1 for <perc@ietf.org>; Fri, 2 Aug 2019 11:48:54 -0700 (PDT)
Received: by mail-oi1-f195.google.com with SMTP id c15so2163028oic.3 for <perc@ietf.org>; Fri, 02 Aug 2019 11:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GYxQR2Vn41Rc+HX6KHQfejw66Ji3Kji3BPFgIkW6VYM=; b=JP6RoUSQDf7K+ckbkeww4JgyhrSG+soQvXHF0DNBLCgGc35xvhHiriF3BR/4v/kyqt olJtHXi4/+jcHgRFf5GH1yl55RnBq649nOkHccTzM4HhDZSU+TIWqeUfcpMFzAPcjoVb Q2pqG/G22otaCce93xeEpQIjP/0W7aOI6TCty67Xy2XB45e+ZxHlLIhjKHqcP4lRJ2lJ E4NK8+yecpzXp+FgOkTZyTSqBZ+uFYhvorUC+wGPRJ+C77WzyxcqMKyXWM9tJ9cxd6SH vQsKW6n8CIPRAa3Q0zR1aqzHEpuDqVI2i30H1dhhkuWlhMalVtKPoz/OGW95pM9n/rFn ki/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GYxQR2Vn41Rc+HX6KHQfejw66Ji3Kji3BPFgIkW6VYM=; b=OMxfFlp1SC7r7zbywhTZhK32xRTTL6pNjesrkhLx7NP4+Uqdu95UXaXUimmXCgI0Q1 nWAbm5Yn9zwUK4GZdNZgIoQQMaqvIu2ksSDSW7P6cF7A9FflwTThs1SBgus6MoT0wXPt XVLzz5W1PqqrGmj0gSGsH1/27+AxDDQgkjczhHpRvSycKHGjCr0oNSBqXqZjFBhqpR9R H8Jv5lBiVvPPsH2/LfW7LcUWaow1tLaarvTpCjmj11rF8e6RFoYR35AQY45t71Bld79q 4RKwxOCy+D9AWLJslpw3Ajq+TbRz5qDTAtG5r1wdqb1ieNpKJsI2m73Zj00kTkbjXl9A GNMw==
X-Gm-Message-State: APjAAAWOf2XkqT9sqN2qDyvFuOY7iGWhmYrgk2Q7Ra1jFifl0a+a0jgi eErrQuPjE794igSRFf5lDtY0tKWrM2/M1+v5MhvNBQ==
X-Google-Smtp-Source: APXvYqzNpnY4Don7MHfEBZEJydfr2N3e00oKM0GURshV0zz0c3qO0RbDohZOhlpKCouXeF+hojVWTm84T7Rh6iEYtb4=
X-Received: by 2002:aca:5410:: with SMTP id i16mr3513871oib.36.1564771733146; Fri, 02 Aug 2019 11:48:53 -0700 (PDT)
MIME-Version: 1.0
References: <156339433620.25783.14611652111059201524.idtracker@ietfa.amsl.com>
In-Reply-To: <156339433620.25783.14611652111059201524.idtracker@ietfa.amsl.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 02 Aug 2019 13:48:11 -0500
Message-ID: <CAL02cgRAU=rxP=vAV-Y5T8=nsRB_sJ_fJptURF88pFYAne72Hg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, perc-chairs@ietf.org, Suhas Nandakumar <suhasietf@gmail.com>, perc@ietf.org, draft-ietf-perc-srtp-ekt-diet@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004f2187058f26cf5f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/zXFF-VhGK2GubVSmKmf2s8obtbU>
Subject: Re: [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
Precedence: list
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: Fri, 02 Aug 2019 18:49:00 -0000

On Wed, Jul 17, 2019 at 3:12 PM Benjamin Kaduk via Datatracker <
noreply@ietf.org> wrote:

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

We may have had one in person, but I'm not seeing one in my email history
either.  The short answer is that I don't think any generalization is
needed.

The longer version is: RTP and SRTP packet formats are not intended to
self-describing.  Instead, they rely heavily on external negotiation to
tell the endpoint how to parse the packet.  For example, there is no
standard format for the RTP extension field; the format of the field (and
even the identifiers for individual extensions used therein) are negotiated
in SDP.

In this context, that means that it's up to the application to make good
decisions about which extensions apply.  Note that EKT is already
incompatible with the SRTP MKI mechanism (as noted in the document), as an
example of the types of incompatibilities that application need to navigate.



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

On the HandshakeType: The authors had a fairly extensive (but unfortunately
off-list) discussion with EKR about how to transmit the EKT key.  After
evaluating the full range of options -- from EncryptedExtensions all the
way to the application layer -- the conclusion of that discussion was that
a HandshakeType fit best with the requirements here.  I'm not sure I
understand your worry about the scarcity of HandshakeType values. "Any
standards-track protocol" is basically the highest bar we have; what more
would you ask?  Practically speaking, we are defining new HandshakeType
values at a high enough rate that we seem likely to exhaust the pool.

On the ExtensionType: Thanks for calling that out; I have sent a request to
the mailing list.  Is there a reason that IANA doesn't send those emails,
like they do with other approvals from designated experts?

--Richard



>
>
> ----------------------------------------------------------------------
> 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
>
>
> _______________________________________________
> Perc mailing list
> Perc@ietf.org
> https://www.ietf.org/mailman/listinfo/perc
>