[Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-srtp-ekt-diet-09: (with DISCUSS)
Benjamin Kaduk <kaduk@mit.edu> Tue, 19 February 2019 17:40 UTC
Return-Path: <kaduk@mit.edu>
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 5E81F12950A; Tue, 19 Feb 2019 09:40:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
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.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155059801437.20845.617758365697782940.idtracker@ietfa.amsl.com>
Date: Tue, 19 Feb 2019 09:40:14 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/biX8pfyD6-wnlviqPN4xVwZ-XkE>
Subject: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-srtp-ekt-diet-09: (with DISCUSS)
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: Tue, 19 Feb 2019 17:40:15 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-perc-srtp-ekt-diet-09: 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: ---------------------------------------------------------------------- [this is a placeholder Discuss to indicate a couple of broad issues early; a full review and ballot position is forthcoming] 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?
- [Perc] Benjamin Kaduk's Discuss on draft-ietf-per… Benjamin Kaduk