Hi Theresa, Please see inline below.
On Fri, Oct 26, 2018 at 2:15 AM Theresa Enghardt <[email protected]> wrote: > Dear TAPS, > > having shepherded the minset draft, and, in the process, having seen a > lot of discussion around security, where we mostly pointed to the > security survey draft, I gave this draft another read in the current > version, with a focus on Section 5. > > Thanks for the update, this document was a good read. > > However, I have some comments, which I'm sharing now rather than later, > just in case there's anything which is better discussed in-person in > Bangkok. > > > Right now, the abstract states that this document is a survey of > security protocols. I suggest to add text saying that the document also > provides a minimal set of security features. Essentially, this document > and minset together cover the "minimum requirements of a secure > transport system". That’s a good suggestion. I’ll add it. > 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? > > 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. > > In Section 5.1, what is "unilateral responder authentication", which I > haven't found in other places in the document under this name? This is an oversight that I will correct. It refers to the overwhelmingly common case wherein servers are the only party authenticated in a protocol. > In Section 5.2, "Session caching and management" has no application > dependency. However, later in Section 6.1, we do expose Session Cache > Management to the application. My interpretation is that this is just an > "optimizing" feature, which is why there is no application dependency, > but it is still useful to expose. It might help to make this explicit in > the text. That’s a good suggestion, yes. I’ll note that this is related to the ongoing Cache Context discussion for the TAPS drafts. > > 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? > 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.” > > > Finally, I would be in favor of asking for a Secdir early review to make > sure we're not missing anything in the survey. +1 > > > Thank you again for this draft. I really appreciate that we're > discussing transport security features in this way. And thank you for the comments! Best, Chris
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
