Hi Aaron, On Fri, Oct 26, 2018 at 10:46 AM Aaron Falk <[email protected]> wrote:
> Dear Authors, > > We agreed at the last IETF that the authors would send a note when this > draft was ready for SecDir review. Is it ready? Do you want to talk about > Theresa's comments in Bangkok first? > It is not yet ready. We will send it to SecDir when that changes. I don’t think Theresa’s comments are blockers here. (I’ll spin a new version with her comments for submission when the tracker reopen.) Best, Chris > --aaron > > On 26 Oct 2018, at 5:15, Theresa Enghardt 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". > > > 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. > > 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? > > In Section 5.1, what is "unilateral responder authentication", which I > haven't found in other places in the document under this name? > > 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. > > In Section 5, do we want to mention any security features related to > integrity protection? > > > 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. > > > Finally, I would be in favor of asking for a Secdir early review to make > sure we're not missing anything in the survey. > > > Thank you again for this draft. I really appreciate that we're > discussing transport security features in this way. > > > Best, > Theresa > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
