Secdir last call review of draft-ietf-taps-minset-06
Yaron Sheffer <yaronf.ietf@gmail.com> Mon, 27 August 2018 05:03 UTC
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C04AD130E69; Sun, 26 Aug 2018 22:03:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: secdir@ietf.org
Cc: draft-ietf-taps-minset.all@ietf.org, ietf@ietf.org, taps@ietf.org
Subject: Secdir last call review of draft-ietf-taps-minset-06
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153534622572.11764.16971261463087249495@ietfa.amsl.com>
Date: Sun, 26 Aug 2018 22:03:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/gDlWbsauhXUrAodTInspPHqp2T4>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.27
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Aug 2018 05:03:46 -0000
Reviewer: Yaron Sheffer Review result: Not Ready The whole notion of TAPS is new to me, so I may be missing the point here. This document defines a minimal set of network APIs that should be available to applications, in order to allow multiple different transport protocols to be used as interchangeable plug-ins with minimal or no change to applications. However the document does not cover security, and instead refers readers to a security protocol survey (draft-ietf-taps-transport-security). There's a disconnect here: in many cases we want applications to be aware of security features. For example, a typical TCP-using application should choose whether to enable TLS encryption of the connection (or as a receiver, whether to require encryption), and if TLS is selected, should at the very least receive access to the authenticated address of the connection's peer. In other words, a meaningful minimal set of APIs cannot be defined without considering the effects and requirements of security protocols. Put differently, the application normally treats the transport protocol and the security protocol layered on it as one protocol. Hence the old name of TLS: Secure Socket Layer. The application sees a single socket, not one socket for transport and another for security. This has been the case for TCP for the last 20-odd years, and is unlikely to change any time soon. I have not surveyed the protocols discussed in this draft, and I don't know whether a viable transport-level security protocol exists for each of them. If this is not the case, then I guess the industry is not yet ready for the kind of solution proposed here.
- Secdir last call review of draft-ietf-taps-minset… Yaron Sheffer
- Re: [Taps] Secdir last call review of draft-ietf-… Tommy Pauly
- Re: [Taps] Secdir last call review of draft-ietf-… Benjamin Kaduk
- Re: [Taps] Secdir last call review of draft-ietf-… Aaron Falk
- Re: [Taps] Secdir last call review of draft-ietf-… Yaron Sheffer