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

["Christopher Wood" <[e-mail]>]

Hi Theresa,

Apologies for the delayed response. Please see inline below.

On 27 Oct 2018, at 1:03, Theresa Enghardt wrote:

> 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?

Thanks for clarifying. I addressed this in the following PR:

    https://github.com/mami-project/draft-pauly-transport-security/pull/46/

>
> 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?

Indeed, the transport dependencies as written are not really clear. For 
source
validation, the intent was to capture that this feature is only 
“available”
(and useful) for connectionless transports. I ended up removing them in 
the
PR above since, upon reflection, they seem to only add noise.

>
>>
>>     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.

Fair point. Upon reflection it seems that the PSK feature should 
certainly not
be mandatory for a security protocol, since (a) it’s not supported by 
all surveyed
protocols and (b) it necessarily requires application input. Most modern 
operating
systems have a default trust store which aids in certificate-based 
authentication,
so I think it’s fine to omit any application dependency there. I 
updated the relevant
text in the PR listed above.

>
>>
>>
>>     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.

This is another instance of terminology mismatch that I corrected in the 
PR above.
Indeed, the first mandatory feature listed in -03 as “Segment or 
datagram encryption and authentication”
is meant to be the same thing.

>
> 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.

This is another oversight :-) I hope the PR above clears this up.

>
>>     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.	

Noted. I filed this PR: 
https://github.com/mami-project/draft-pauly-transport-security/pull/45

>
>
> Thanks, and thanks for the discussion!

My pleasure! Thank you again for the comments and feedback.

Best,
Chris