Re: [saag] Fwd: Last Call: <draft-ietf-taps-transport-security-09.txt> (A Survey of Transport Security Protocols) to Informational RFC

Christian Huitema <huitema@huitema.net> Wed, 09 October 2019 02:42 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AF712006D for <saag@ietfa.amsl.com>; Tue, 8 Oct 2019 19:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 SXsFF4OC6a0a for <saag@ietfa.amsl.com>; Tue, 8 Oct 2019 19:42:51 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFA312007A for <saag@ietf.org>; Tue, 8 Oct 2019 19:42:51 -0700 (PDT)
Received: from xse380.mail2web.com ([66.113.197.126] helo=xse.mail2web.com) by mx12.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1iI1w7-0006pS-7P for saag@ietf.org; Wed, 09 Oct 2019 04:42:49 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46nz5w2TpBz3CjT for <saag@ietf.org>; Tue, 8 Oct 2019 19:42:44 -0700 (PDT)
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1iI1w4-0004hA-7D for saag@ietf.org; Tue, 08 Oct 2019 19:42:44 -0700
Received: (qmail 24778 invoked from network); 9 Oct 2019 02:42:43 -0000
Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender <huitema@huitema.net>) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for <saag@ietf.org>; 9 Oct 2019 02:42:43 -0000
From: Christian Huitema <huitema@huitema.net>
To: Benjamin Kaduk <kaduk@mit.edu>, saag@ietf.org
References: <157019735697.1122.6295466344059123434.idtracker@ietfa.amsl.com> <20191006161144.GV6722@kduck.mit.edu> <a1391f98-80e2-fa25-f64b-b7e63cb82ec1@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <3278891e-a18f-4045-6efb-34d76d608352@huitema.net>
Date: Tue, 8 Oct 2019 19:42:42 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1
MIME-Version: 1.0
In-Reply-To: <a1391f98-80e2-fa25-f64b-b7e63cb82ec1@huitema.net>
Content-Type: multipart/alternative; boundary="------------952407BE5796FA7723A006FD"
Content-Language: en-US
X-Originating-IP: 66.113.197.126
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ezqdolHG91LK5q2HN6uCHCpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDRitNmXY60Gx0fFyUeQSRQrgN zB/4Jkrw1eDLcif59fvYghnsr4imsy708TXlwpzMU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5hmwN8D4LrepG7AX8WNwY8fOdU2kQFJEzfkq4ITozmM46jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhMjx7v77N42Z/zX3DQBtZa/0j9rMdVQseW3F+doIupqmER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnHY2vFR2X3V3 u1DLkE7IQAkcUbp3Bqu4p2xgXhpsPNPB69BsSJSxcyfz9l7PtUpARgeYUOp7A73HI6oJg7w/VocK FIxNlsy2WJpil5s07kEDyBw3j/aBxjxoZyMqfIL/jJq7xqDoiTjjGpNS1XGXbXI/CQeOLSIbTLMj Ll707sxvAztqzrCt4TZ/wLtujY/tpUpf8ouLb5QDITSNRDXKSuNIsNTbWtIINgLIkbhCu78rPAlb DjazCbhs7qBpykynMha5/rijjcguRYfyvX/qs6BGikecEG2YoGT07Mx+/Nev83g9ueTJOU6a76yp yxjdeg8YhWenlMfuvb1mNY5/IPiuedK/Z3MvnAyDmuOaA5CGZRWsGw8ac2InzcAP/gmxwNpms+rB 6wJM+NNhN3aT35NSU/fjw6KbqLw80r1gDO3m6U0LjBzYuQztdAThgtWSU3qCINKqlAdh+ePAcEwD s/8=
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/43g1LfmbbL1F5BoUHTwyOleHJU0>
Subject: Re: [saag] Fwd: Last Call: <draft-ietf-taps-transport-security-09.txt> (A Survey of Transport Security Protocols) to Informational RFC
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Oct 2019 02:42:55 -0000

Please disregard my previous message. I got my email very confused, and
reviewed a TSVWG draft instead of draft-ietf-taps-transport-security-09.txt.

My assessment of draft-ietf-taps-transport-security-09.txt would be
pretty close to EKR's review.

The TAPS architecture assumes some kind of "protocol agnostic" API.
Applications would specify the transport features that they want using
an abstract definition, and the TAPS implementation would then
automatically select among the implementations available on the
platform. In the target scenario, the application could specify
something like "encrypted connection, authenticating the server, and
providing a reliable stream". The platform could then select "SCTP over
DTLS", or "TLS over TCP", or "QUIC". I personally have serious doubts
about the viability of such scenarios. Protocols like QUIC or TLS are
implemented in application space and shipped with the application code,
so an application can guarantee that its protocol of choice is available
without going through a selection API. But the IETF did charter the TAPS
working group and that's what it does.

Based on the TAPS charter, the authors go on to inventory a set of
security protocols and attempt to characterize them by drawing a set of
properties. I agree with EKR's observation that the proposed
classification feels somewhat arbitrary. Can we really compare IPSEC and
TLS by checking whether they support pre-shared keys or source
validation? Can we do that without analyzing the type of identities
supported by these protocols? Obviously, much of the security properties
are function of something else that API features. Can we compare TLS 1.0
negotiating RC4 to TLS 1.3 negotiating AES128-GCM? If we really dream of
protocol selection APIs as envisaged in the TAPS charter, should it
expose available algorithms as well as stated features? Does it matter
whether there is a formal proof available for the protocol design?

In fact, this document begs another question. It is a product of a
transport area working group trying to compare properties of protocols
defined in the security area. It is applying the same methodology to
comparing security protocols that it used for comparing UDP, TCP and
SCTP. Clearly, some of the authors do have security expertise, but
that's the working group as a whole does not. Should the transport area
write down assessments of security protocols?

-- Christian Huitema

On 10/8/2019 3:04 PM, Christian Huitema wrote:
>
> As the draft mentions:
>
>    The use of transport layer authentication and encryption exposes a
>    tussle between middlebox vendors, operators, applications developers
>    and users
>
> Much of the draft content goes on explaining the middlebox vendors'
> view of that tussle. As such, the draft is not terribly helpful...
>
> On 10/6/2019 9:12 AM, Benjamin Kaduk wrote:
>> I think several folks have taken an early look at this one; now would be a
>> great time to take a second look.
>>
>> -Ben
>>
>> On Fri, Oct 04, 2019 at 06:55:56AM -0700, The IESG wrote:
>>> The IESG has received a request from the Transport Services WG (taps) to
>>> consider the following document: - 'A Survey of Transport Security Protocols'
>>>   <draft-ietf-taps-transport-security-09.txt> as Informational RFC
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits final
>>> comments on this action. Please send substantive comments to the
>>> ietf@ietf.org mailing lists by 2019-10-18. Exceptionally, comments may be
>>> sent to iesg@ietf.org instead. In either case, please retain the beginning of
>>> the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>>    This document provides a survey of commonly used or notable network
>>>    security protocols, with a focus on how they interact and integrate
>>>    with applications and transport protocols.  Its goal is to supplement
>>>    efforts to define and catalog transport services by describing the
>>>    interfaces required to add security protocols.  This survey is not
>>>    limited to protocols developed within the scope or context of the
>>>    IETF, and those included represent a superset of features a Transport
>>>    Services system may need to support.  Moreover, this document defines
>>>    a minimal set of security features that a secure transport system
>>>    should provide.
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/
>>>
>>> IESG discussion can be tracked via
>>> https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ballot/
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> IETF-Announce mailing list
>>> IETF-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag