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
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
