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

From: [email-masked]
Date: Mon, 22 Oct 2018 09:58:00 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Services WG of the IETF.

        Title           : A Survey of Transport Security Protocols
        Authors         : Tommy Pauly
                          Colin Perkins
                          Kyle Rose
                          Christopher A. Wood
	Filename        : draft-ietf-taps-transport-security-03.txt
	Pages           : 33
	Date            : 2018-10-22

Abstract:
   This document provides a survey of commonly used or notable network
   security protocols, with a focus on how they interact and integrate
   with applications and transport protocols.  Its goal is to supplement
   efforts to define and catalog transport services [RFC8095] by
   describing the interfaces required to add security protocols.  It
   examines Transport Layer Security (TLS), Datagram Transport Layer
   Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
   TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with
   Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and
   WireGuard.  This survey is not limited to protocols developed within
   the scope or context of the IETF, and those included represent a
   superset of features a TAPS system may need to support.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-taps-transport-security-03
https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transport-security-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Theresa Enghardt <[email-masked]>
Date: Fri, 26 Oct 2018 11:15:11 +0200

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

---

From: Aaron Falk <[email-masked]>
Date: Fri, 26 Oct 2018 13:46:25 -0400

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?

--aaron

---

From: Christopher Wood <[email-masked]>
Date: Fri, 26 Oct 2018 22:05:46 -0700

Hi Theresa,

Please see inline below.

> and minset together cover the "minimum requirements of a secure

That’s a good suggestion. I’ll add it.

> contrast, a "function" feature needs to be exposed to the application.

What specifically do you think should change here?

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

> haven't found in other places in the document under this name?

This is an oversight that I will correct. It refers to the overwhelmingly
common case wherein servers are the only party authenticated in a protocol.

> but it is still useful to expose. It might help to make this explicit in

That’s a good suggestion, yes. I’ll note that this is related to the
ongoing Cache Context discussion for the TAPS drafts.

> In Section 5, do we want to mention any security features related to

No, I don’t think so. What would be the purpose?

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

> sure we're not missing anything in the survey.

+1

> discussing transport security features in this way.

And thank you for the comments!

Best,
Chris

---

From: Christopher Wood <[email-masked]>
Date: Fri, 26 Oct 2018 22:07:47 -0700

Hi Aaron,

On Fri, Oct 26, 2018 at 10:46 AM Aaron Falk <[email-masked]> wrote:

> 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

> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>

---

From: Theresa Enghardt <[email-masked]>
Date: Sat, 27 Oct 2018 10:03:34 +0200

Hi Chris,

I'm replying to your questions inline:

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

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?

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

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

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

Thanks, and thanks for the discussion!

Best,
Theresa