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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
