[secdir] Security review of draft-ietf-perc-srtp-ekt-diet-08

"Hilarie Orman" <hilarie@purplestreak.com> Wed, 31 October 2018 20:38 UTC

Return-Path: <hilarie@purplestreak.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 510B6130D7A; Wed, 31 Oct 2018 13:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id sTIAsP1Ul_zq; Wed, 31 Oct 2018 13:38:55 -0700 (PDT)
Received: from out01.mta.xmission.com (out01.mta.xmission.com []) (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 91C08130DC2; Wed, 31 Oct 2018 13:38:55 -0700 (PDT)
Received: from in01.mta.xmission.com ([]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from <hilarie@purplestreak.com>) id 1gHxGQ-0003Zc-F3; Wed, 31 Oct 2018 14:38:54 -0600
Received: from [] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from <hilarie@purplestreak.com>) id 1gHxGP-000112-MO; Wed, 31 Oct 2018 14:38:54 -0600
Received: from rumpleteazer.rhmr.com (localhost []) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w9VKcZG7013490; Wed, 31 Oct 2018 14:38:35 -0600
Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id w9VKcZmV013489; Wed, 31 Oct 2018 14:38:35 -0600
Date: Wed, 31 Oct 2018 14:38:35 -0600
Message-Id: <201810312038.w9VKcZmV013489@rumpleteazer.rhmr.com>
From: "Hilarie Orman" <hilarie@purplestreak.com>
Reply-To: "Hilarie Orman" <hilarie@purplestreak.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-perc-srtp-ekt-diet.all@ietf.org
X-XM-SPF: eid=1gHxGP-000112-MO; ; ; mid=<201810312038.w9VKcZmV013489@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-AID: U2FsdGVkX183ama5UV+jxaMaxUNSBPfJ
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1
X-Spam-Combo: ****;iesg@ietf.org, secdir@ietf.org, draft-ietf-perc-srtp-ekt-diet.all@ietf.org
X-Spam-Timing: total 321 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 10 (3.0%), b_tie_ro: 4.5 (1.4%), parse: 0.66 (0.2%), extract_message_metadata: 3.6 (1.1%), get_uri_detail_list: 1.40 (0.4%), tests_pri_-1000: 2.6 (0.8%), tests_pri_-950: 1.20 (0.4%), tests_pri_-900: 1.02 (0.3%), tests_pri_-90: 27 (8.4%), check_bayes: 26 (8.0%), b_tokenize: 6 (1.8%), b_tok_get_all: 6 (1.9%), b_comp_prob: 2.4 (0.7%), b_tok_touch_all: 9 (2.9%), b_finish: 0.64 (0.2%), tests_pri_0: 262 (81.7%), check_dkim_signature: 0.47 (0.1%), check_dkim_adsp: 26 (8.2%), tests_pri_10: 3.1 (1.0%), tests_pri_500: 8 (2.5%), rewrite_mail: 0.00 (0.0%)
X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600)
X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/B4igA2t1wFx7fJPPhSV_Y8a4HaA>
Subject: [secdir] Security review of draft-ietf-perc-srtp-ekt-diet-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Oct 2018 20:38:58 -0000

Security review of Encrypted Key Transport for DTLS and Secure RTP

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call

The draft defines a way by which each sender in a multi-participant
session can communicate its encrypting key (called a "master key") to
the other participants.  In this scheme, all participants learn a
key encrypting key (EKTKey) that is used to protect sender's
encrypting keys during transit.

"This specification also defines a way to send the encrypted SRTP
   master key (with the EKTKey) along with the SRTP packet ...
   Endpoints that receive this and know the EKTKey can use the EKTKey
   to decrypt the SRTP master key which can then be used to decrypt
   the SRTP packet."

I think that the paragraph above would be clearer if "(with the
EKTkey)" were changed to "(encrypted with the EKTkey)".

I do not understand the security model.  If all participants know the
EKTkey, then why do senders need to separately select their own
individual keys?  Cannot all participants use something derived from
the EKTkey?  Is this a legacy thing?  

Section 4.4 states that
   "EKT uses an authenticated cipher to encrypt and authenticate the

Also section 6 (security considerations) states:
   The EKT Cipher includes its own authentication/integrity check.  For
   an attacker to successfully forge a FullEKTField, it would need to
   defeat the authentication mechanisms of the EKT Cipher authentication

Section 4.4.1 state "The default EKT Cipher is the Advanced Encryption
   Standard (AES) Key Wrap with Padding [RFC5649] algorithm."

RFC5649 does not purport to define an authenticated cipher.  I am not
sure what properties of RFC5649 are the ones that are considered
important, so I cannot recommend appropriate wording, though I suspect
that "integrity" is the right word, not "authentication".

I have one concern about the requirement that all senders change their
keys when the EKTKey changes.  Suppose a malicious participant manages
to create a replay attack that sends a EKTkey message with a key that
was previously used, perhaps even the same one that is currently used.
This would force all participants to change their keys, perhaps at a
very high rate, and this might lead to denial of service.
Participants might be advised to ignore EKTkey messages that repeat
the current EKTkey.