Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt

Hi, Christopher,

On Sat, Oct 27, 2018 at 12:08 AM Christopher Wood <
christopherwood07@gmail.com> wrote:

> Hi Aaron,
>
> On Fri, Oct 26, 2018 at 10:46 AM Aaron Falk <aafalk@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
>