Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt
Theresa Enghardt <theresa@inet.tu-berlin.de> Sat, 27 October 2018 08:03 UTC
Return-Path: <theresa@inet.tu-berlin.de>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26816128D68 for <taps@ietfa.amsl.com>; Sat, 27 Oct 2018 01:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 NjCirKKemIYM for <taps@ietfa.amsl.com>; Sat, 27 Oct 2018 01:03:36 -0700 (PDT)
Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:638:809:ff20:130:149:152:141]) by ietfa.amsl.com (Postfix) with ESMTP id D366312785F for <taps@ietf.org>; Sat, 27 Oct 2018 01:03:35 -0700 (PDT)
Received: from [192.168.178.160] (ip-95-222-96-215.hsi15.unitymediagroup.de [95.222.96.215]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id BD45320228; Sat, 27 Oct 2018 10:03:34 +0200 (CEST)
To: Christopher Wood <christopherwood07@gmail.com>
Cc: taps@ietf.org
References: <154022748014.6890.5464777930050299508@ietfa.amsl.com> <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> <CAO8oSXkNDXOn_C-OOFcLQeZS94pZVgjT4AnvuD8wV76M=RDPyQ@mail.gmail.com>
From: Theresa Enghardt <theresa@inet.tu-berlin.de>
Message-ID: <302b8870-2473-8ae3-b196-7c62850c97c1@inet.tu-berlin.de>
Date: Sat, 27 Oct 2018 10:03:34 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAO8oSXkNDXOn_C-OOFcLQeZS94pZVgjT4AnvuD8wV76M=RDPyQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------95E3DA2867DF4B90491D16D9"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/F9S_AV_N53zWuFOKzEfoc_MwDrA>
Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Oct 2018 08:03:38 -0000
Hi Chris, I'm replying to your questions inline: On 27.10.2018 07:05, Christopher Wood wrote: > > > In Section 5, the document groups security features into mandatory and > optional features, and states their transport dependency and > application > dependency. Application dependency, for me, relates to whether a > feature > is "functional", "optimizing", or "automatable" (in minset > terminology). > For example, if there is no application dependency, the feature is > "automatable" and does not have to be exposed to the application. In > contrast, a "function" feature needs to be exposed to the application. > > > What specifically do you think should change here? I suggest to define "application dependency" at the beginning of Section 5 -- it states what the application needs to know about the security feature for it to work, right? Is the application knowing about the feature always mandatory, or is this sometimes optional? Additionally, it might be useful to define what we mean by "transport dependency". If this means that a security feature can only be provided when a certain transport feature is in place, then I'm not sure I understand the transport dependency of "Source validation". Does this mean that source validation only works with streams? Or does it work differently depending on whether we have streams or datagrams? > > In Section 5.1, I am missing transport dependency and application > dependency for the mandatory transport features. For example, I > would be > interested to know what is the minimum that the transport system needs > to expose to the application for public-key based authentication? > > > The mandatory features are those which must be provided regardless of > the transport features. Thus, we list no transport dependencies. I see, and I think it would help me to reduce confusion to clarify this in the document. Are there any application dependencies for mandatory transport features? For example, I would expect at least public-key authentication and pre-shared key support to be application-dependent. > > > In Section 5, do we want to mention any security features related to > integrity protection? > > > No, I don’t think so. What would be the purpose? For example, "Record (channel or datagram) confidentiality and integrity" is defined as a security feature in Section 3, but then not mentioned in Section 5 at all. This surprises me as a reader, I would have expected it to be listed as a mandatory feature. Perhaps it is reflected as "segment or datagram encryption and authentication", which was actually the definition of "Record (channel or datagram) confidentiality and integrity" given in Section 3, but then I'm confused about the change in terminology. As another example: "Optional record integrity" shows up in Section 3 but not in Section 5. If Section 5 is just a subset of the security features listed in Section 3, I would appreciate some text in Section 5 to explain why these features were chosen and not others. > As far as I can see, none of the protocols we survey provide any > features explicitly providing privacy. Maybe this is worth > highlighting > in the Security considerations section, beyond saying that no > claims of > privacy properties are made. > > > This is a tough one. Depending on one’s level of pessimism, none of > these protocols provide much in the way of privacy. However, in the > case of TLS, we often think of privacy as confidentiality of data > involved. Information is often leaked in other ways, e.g., via the > SNI. It all boils down to your definition of privacy, of which we have > no formal definition. Thus, I’m hesitant to say more than, e.g., “we > do not consider privacy aspects of security protocols.” I understand, but I would also find it very interesting to at least mention, e.g., (reduction of) information leakage as an aspect related to privacy. I'm not sure it could be formalized as a security features, given the lack of formal definition of privacy. Thanks, and thanks for the discussion! Best, Theresa
- [Taps] I-D Action: draft-ietf-taps-transport-secu… internet-drafts
- Re: [Taps] I-D Action: draft-ietf-taps-transport-… Theresa Enghardt
- Re: [Taps] I-D Action: draft-ietf-taps-transport-… Aaron Falk
- Re: [Taps] I-D Action: draft-ietf-taps-transport-… Christopher Wood
- Re: [Taps] I-D Action: draft-ietf-taps-transport-… Christopher Wood
- Re: [Taps] I-D Action: draft-ietf-taps-transport-… Theresa Enghardt
- Re: [Taps] I-D Action: draft-ietf-taps-transport-… Spencer Dawkins at IETF
- Re: [Taps] I-D Action: draft-ietf-taps-transport-… Christopher Wood
- Re: [Taps] I-D Action: draft-ietf-taps-transport-… Spencer Dawkins at IETF
- Re: [Taps] I-D Action: draft-ietf-taps-transport-… Christopher Wood