Hi, Christopher, On Sat, Oct 27, 2018 at 12:08 AM Christopher Wood < christopherwoo...@gmail.com> wrote:
> Hi Aaron, > > On Fri, Oct 26, 2018 at 10:46 AM Aaron Falk <aaf...@akamai.com> 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.) > Given that TAPS meets fairly late on Wednesday, if you think there will be discussion that a SECDIR reviewer might benefit from, it is likely possible to let the secdir secretaries at https://datatracker.ietf.org/group/secdir/about/ know that a request for early review will be coming, so that a reviewer could be identified early enough to be present. If that won't be a helpful discussion for a reviewer to listen to, of course, no need. Do the right thing :-) Spencer > 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 >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
