Skip to main content

A Survey of the Interaction between Security Protocols and Transport Services
draft-ietf-taps-transport-security-12

Revision differences

Document history

Date Rev. By Action
2020-10-13
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-09-21
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-06-15
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-04-29
12 (System) IANA Action state changed to No IANA Actions from In Progress
2020-04-27
12 (System) RFC Editor state changed to EDIT
2020-04-27
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-04-27
12 (System) Announcement was received by RFC Editor
2020-04-27
12 (System) IANA Action state changed to In Progress
2020-04-27
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-04-27
12 Amy Vezza IESG has approved the document
2020-04-27
12 Amy Vezza Closed "Approve" ballot
2020-04-27
12 Magnus Westerlund IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-04-27
12 Magnus Westerlund Ballot approval text was generated
2020-04-23
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-04-23
12 Tommy Pauly New version available: draft-ietf-taps-transport-security-12.txt
2020-04-23
12 (System) New version accepted (logged-in submitter: Tommy Pauly)
2020-04-23
12 Tommy Pauly Uploaded new revision
2020-04-16
11 Susan Hares Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Susan Hares. Sent review to list.
2020-04-15
11 Paul Wouters Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Paul Wouters. Sent review to list.
2020-04-13
11 Aaron Falk This document now replaces draft-pauly-taps-transport-security instead of None
2020-04-09
11 Martin Duke
[Ballot comment]
These taps Informational RFCs are going to be bound together and make a great textbook someday.

One nit: In section 5.3, you note …
[Ballot comment]
These taps Informational RFCs are going to be bound together and make a great textbook someday.

One nit: In section 5.3, you note that TLS supports key export. IIRC, this is only TLS 1.3. It might be worthwhile to specify it is 1.3 only.
2020-04-09
11 Martin Duke [Ballot Position Update] New position, Yes, has been recorded for Martin Duke
2020-04-09
11 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. It is really easy to read.

After discussion with Magnus and Barry, I have …
[Ballot comment]
Thank you for the work put into this document. It is really easy to read.

After discussion with Magnus and Barry, I have cleared my DISCUSS but I still hope for a fix to my previous DISCUSS

Please find below some non-blocking COMMENTs. An answer will still be appreciated.

I hope that this helps to improve the document,

Regards,

-éric

== previous DISCUSS ==

I question the inclusion of CurveCP in the mix as per https://curvecp.org/addressing.html it does not seem to support IPv6. At the bare minimum, the I-D should mention this restriction in section 3 or rename section 3 from "protocol descriptions" into something less exhaustive.

(and I hope to be corrected about CurveCP IPv6 support).

== COMMENT ==

Please respond to the IoT-directorate review by Mohit: https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI78sDPZQuVsTvGB2x0s
Please respond to the INT-DIR review by Brian: https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7TXvo_ujcI_I + Gorry Fairhurst's about GRE

Generic comment about the intended transport: all protocols analyzed in this document are point to point (no multicast), this should probably be mentioned in the introduction.

-- Section 1 --
Is there any reason why the integrity property of IPsec AH is not mentioned ? Same also applies in section 2 when "security protocol" is defined.

-- Section 3 --
Use the wording of "record protocol" generically while the term "record protocol" is defined in section 2 as a blocked data transport (like in TLS). Suggest the use of "data transfer protocol" ?

An important property of such protocols is to be able to traverse a NAPT box (that I hate)... I suggest to mention whether the analyzed protocols support NAT-traversal in this description section or even in the analysis parts as having a different view (application and network layers seeing possibly different IP addresses so a potential impact on the API).
2020-04-09
11 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss
2020-04-09
11 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2020-04-09
11 Éric Vyncke
[Ballot discuss]
Thank you for the work put into this document. It is really easy to read.

Nevertheless, I am balloting a DISCUSS (see below), …
[Ballot discuss]
Thank you for the work put into this document. It is really easy to read.

Nevertheless, I am balloting a DISCUSS (see below), I sincerely hope that I am wrongly asserting the lack of IPv6 support for CurveCP else the easy way to clear my DISCUSS would be to mention this limitation in section 3 even if the focus of this I-D is on the API.

Please find below some non-blocking COMMENTs. An answer will be appreciated.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

I question the inclusion of CurveCP in the mix as per https://curvecp.org/addressing.html it does not seem to support IPv6. At the bare minimum, the I-D should mention this restriction in section 3.
(and I hope to be corrected about CurveCP IPv6 support).
2020-04-09
11 Éric Vyncke
[Ballot comment]
Please respond to the IoT-directorate review by Mohit: https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI78sDPZQuVsTvGB2x0s
Please respond to the INT-DIR review by Brian: https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7TXvo_ujcI_I + Gorry Fairhurst's about GRE …
[Ballot comment]
Please respond to the IoT-directorate review by Mohit: https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI78sDPZQuVsTvGB2x0s
Please respond to the INT-DIR review by Brian: https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7TXvo_ujcI_I + Gorry Fairhurst's about GRE

Generic comment about the intended transport: all protocols analyzed in this document are point to point (no multicast), this should probably be mentioned in the introduction.

-- Section 1 --
Is there any reason why the integrity property of IPsec AH is not mentioned ? Same also applies in section 2 when "security protocol" is defined.

-- Section 3 --
Use the wording of "record protocol" generically while the term "record protocol" is defined in section 2 as a blocked data transport (like in TLS). Suggest the use of "data transfer protocol" ?

An important property of such protocols is to be able to traverse a NAPT box (that I hate)... I suggest to mention whether the analyzed protocols support NAT-traversal in this description section or even in the analysis parts as having a different view (application and network layers seeing possibly different IP addresses so a potential impact on the API).
2020-04-09
11 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2020-04-08
11 Alissa Cooper
[Ballot comment]
To a non-expert it struck me as a bit odd that Dan Bernstein is mentioned as the designer of CurveCP but no one …
[Ballot comment]
To a non-expert it struck me as a bit odd that Dan Bernstein is mentioned as the designer of CurveCP but no one is mentioned as the designer of MinimalT.
2020-04-08
11 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2020-04-08
11 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2020-04-08
11 Benjamin Kaduk
[Ballot comment]
I do wonder whether the Generic Security Service API (RFC 2743) was
considered by the WG in the production of this …
[Ballot comment]
I do wonder whether the Generic Security Service API (RFC 2743) was
considered by the WG in the production of this document.  It reflects a
somewhat dated snapshot of what was believed to be necessary security
APIs, but may not be entirely without value for this type of survey.

It's a little surprising to not list a reference for QUIC in its
mentions in Sections 1 and 3, with the first reference occuring in
Section 3.3.1.

Section 1

  set, protocols that do not offer new features are omitted.  For
  example, newer protocols such as WireGuard make unique design choices
  that have implications and limitations on application usage.  In

nit: "implications for" and "limitations on".

  protection.  Despite these improvements, neither protocol sees
  general use and both lack critical properties important for emergent
  transport security protocols: confidentiality, privacy protections,
  and agility.  Such protocols are thus omitted from this survey.

I don't think I see how TCP-AO and IPsec AH lack "agility".  Could you
clarify what was intended?

Section 1.2

  It is not a goal to allow software implementations to automatically
  switch between different security protocols, even where their
  interfaces to transport and applications are equivalent.  Even
  between versions, security protocols have subtly different guarantees
  and vulnerabilities.  [...]

Another impactful distinction between security protocols is in how they
name and authenticate the communications peer -- I can't imagine writing
a useful API that tries to abstract out the X.509 DNS-ID naming for TLS,
SSH host key fingerprints, etc.

Section 2

Should we reference RFC 8095 at the appropriate definitions [that we
duplicate from it]?

  *  Transport Protocol: an implementation that provides one or more
      different transport services using a specific framing and header
      format on the wire.  A Transport Protocol services an application.

(whether directly or with an intermediating security protocol?)

Section 3.1.1

  protocol.  The handshake protocol is used to authenticate peers,
  negotiate protocol options, such as cryptographic algorithms, and
  derive session-specific keying material.  The record protocol is used
  to marshal (possibly encrypted) data from one peer to the other.

My inference is that the "possibly encrypted" is supposed to refer to
the encryption performed by the TLS record layer itself, as opposed to
having already-encrypted data supplied to TLS as "Application Data".  If
correct, I'd suggest rewording to "is used to marshal and, once the
handshake has sufficiently progressed, encrypt, data from one peer to
the other".

Section 3.1.2

DTLS doesn't provide "the same security guarantees as TLS" in the
general case.  Specifically, redord replay detection is only optional in
DTLS whereas it is inherently provided in TLS.

Section 3.4.2

  WireGuard is an IP-layer protocol designed as an alternative to IPsec
  [WireGuard] for certain use cases.  It uses UDP to encapsulate IP

Please move the location of the reference; it currently scans like it's
a reference for IPsec(!).

Section 5.1

  *  Identities and Private Keys (IPK): The application can provide its
      identities (certificates) and private keys, or mechanisms to
      access these, to the security protocol to use during handshakes.

I think it would be more accurate to say "provide its identity,
credentials (e.g., certificates), and private keys" -- a certificate is
not exactly an identity, but rather an attestation thereof provided by a
(nominally) trusted authority.  Not all security protocols use
certificates in all cases, so I also think the "e.g." is appropriate.

Section 5.2

  *  Source Address Validation (SAV): The handshake protocol may
      delegate validation of the remote peer that has sent data to the
      transport protocol or application.  This involves sending a cookie
      exchange to avoid DoS attacks.

I'm not sure I understand the intent of using the word "delegate" here.

  *  Mobility Events (ME): The record protocol can be signaled that it
      is being migrated to another transport or interface due to
      connection mobility, which may reset address and state validation
      and induce state changes such as use of a new Connection
      Identifier (CID).

I think it's expected that DTLS 1.3 will do this (though I note that you
aren't currently referencing DTLS 1.3).

Section 8

  omitted from this survey.  All security protocols surveyed generally
  improve privacy by reducing information leakage via encryption.

nit: I suggest "improve privacy by using encryption to reduce
information leakage" (to avoid the misparse of "reducing (information
(leakage via encryption))").
2020-04-08
11 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-04-08
11 Deborah Brungard [Ballot comment]
Nice document!
2020-04-08
11 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-04-07
11 Barry Leiba
[Ballot comment]
Thanks for this helpful document.  Just some editorial comments beyond what others have mentioned:

— Section 1 —

  It examines Transport Layer …
[Ballot comment]
Thanks for this helpful document.  Just some editorial comments beyond what others have mentioned:

— Section 1 —

  It examines Transport Layer Security
  (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google
  QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating
  Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard,
  CurveCP, and MinimalT.

It’s funny that this carefully expands every abbreviation except “SRTP”.  Please do that one too.

  Ubiquitous IETF protocols such as (D)TLS, as well as non-standard
  protocols such as gQUIC, are both included

The word “both” doesn’t work here.  I think a reasonable fix is just to remove the single word.  Maybe a better fix is to slightly reword, as, “Ubiquitous IETF protocols such as (D)TLS are included, and so are non-standard protocols such as gQUIC, despite...”

— Section 1.1 —

  For example, a security
  protocol that expects to run over a reliable stream of bytes, like
  TLS, restrict the set of transport protocols that can be used

Number agreement: make it “restricts” to match the singular subject “a security protocol”.

— Section 2 —

      Examples include
      confidentiality, reliable delivery, ordered delivery, message-
      versus-stream orientation, etc.

You don’t need both “examples include” and “etc.”; I suggest eliminating the latter (and sticking in an “and”).

— Section 3.1.1 —

  to marshal (possibly encrypted) data from one peer to the other.

Possibly?  I understand you’re covering the handshake there as well, but for a summary as (reasonably) brief as this I think it’s misleading to say “possibly”.

— Section 3.2.1 —

  ZRTP [RFC6189] is an alternative key agreement and identity
  management protocols for SRTP.

Number agreement: “protocol”

— Section 3.4.3 —

  For key establishment, OpenVPN can use TLS as a handshake protocol or
  pre-shared keys.

This reads oddly, as though there are two things OpenVPN can use TLS for.  I would make it, “...or it can use pre-shared keys.”

— Section 5.1 —

  *  Extensions (Application-Layer Protocol Negotiation) (EXT): The
      application enables or configures extensions that are to be
      negotiated by the security protocol, such as ALPN [RFC7301].

Isn’t the expansion of “ALPN” misplaced here?
2020-04-07
11 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-04-07
11 Alvaro Retana [Ballot comment]
This document should be tagged as replacing draft-pauly-taps-transport-security.
2020-04-07
11 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-04-07
11 Warren Kumari
[Ballot comment]
Not much that I can add, other than that I really like these type of documents - the IETF has a huge number …
[Ballot comment]
Not much that I can add, other than that I really like these type of documents - the IETF has a huge number of documents, and it's really hard for people to know where to start, especially with this sort of topic.
2020-04-07
11 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-04-06
11 Robert Wilton
[Ballot comment]
As incoming AD I found that document really useful and informative - thank you.

As a minor nit, I found the English around …
[Ballot comment]
As incoming AD I found that document really useful and informative - thank you.

As a minor nit, I found the English around the usage of the term "Transport Services", that I wasn't familiar with prior to reading this document, slightly tricky to parse in the introduction, particularly because the term isn't defined until the Terminology in section 3.

E.g. in the second paragraph it isn't clear to me what a "Transport Services system" real means.  Possibly replace "a Transport Services system may need to support" with "a Transport Service may need to support"?

Similarly, perhaps change " One of the goals of Transport Services is to define a common interface for using transport protocols" to " One of the goals of Transport Service definitions is to define a common interface for using transport protocols"?
2020-04-06
11 Robert Wilton [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton
2020-04-05
11 Erik Kline
[Ballot comment]
{Yes}

[nits]

S4.3

* s/Specific,/Specifically,/

* s/a dependencies/a dependency ?/

S5.3

* Does https://tools.ietf.org/html/rfc8446#section-4.6.3 count as supporting
  Key Expiration?  Maybe not because …
[Ballot comment]
{Yes}

[nits]

S4.3

* s/Specific,/Specifically,/

* s/a dependencies/a dependency ?/

S5.3

* Does https://tools.ietf.org/html/rfc8446#section-4.6.3 count as supporting
  Key Expiration?  Maybe not because the send is expected to observe the need
  to rekey and do so, rather than something in the record protocol itself.
  Is that a correct reading?
2020-04-05
11 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2020-04-03
11 Tero Kivinen Request for Telechat review by SECDIR is assigned to Paul Wouters
2020-04-03
11 Tero Kivinen Request for Telechat review by SECDIR is assigned to Paul Wouters
2020-04-03
11 Brian Haberman Request for Telechat review by INTDIR Completed: Ready with Issues. Reviewer: Brian Haberman. Sent review to list.
2020-04-01
11 Mohit Sethi Request for Telechat review by IOTDIR Completed: Ready with Nits. Reviewer: Mohit Sethi. Sent review to list.
2020-03-31
11 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Susan Hares
2020-03-31
11 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Susan Hares
2020-03-30
11 Samita Chakrabarti Request for Telechat review by IOTDIR is assigned to Mohit Sethi
2020-03-30
11 Samita Chakrabarti Request for Telechat review by IOTDIR is assigned to Mohit Sethi
2020-03-28
11 Murray Kucherawy
[Ballot comment]
This is a really useful summary, especially for people without deep background in transport security.  It'll make a great reference document.

Section 4.3: …
[Ballot comment]
This is a really useful summary, especially for people without deep background in transport security.  It'll make a great reference document.

Section 4.3:
* "Specific" should be "Specifically"
* "They have a dependencies on" -- should be "dependency"
2020-03-28
11 Murray Kucherawy [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy
2020-03-27
11 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-03-26
11 Bernie Volz Request for Telechat review by INTDIR is assigned to Brian Haberman
2020-03-26
11 Bernie Volz Request for Telechat review by INTDIR is assigned to Brian Haberman
2020-03-26
11 Éric Vyncke Requested Telechat review by IOTDIR
2020-03-26
11 Éric Vyncke Requested Telechat review by INTDIR
2020-03-26
11 Magnus Westerlund Notification list changed to Philipp Tiesel <philipp@tiesel.net>, caw@heapingbits.net from Philipp Tiesel <philipp@tiesel.net>
2020-03-25
11 Amy Vezza Placed on agenda for telechat - 2020-04-09
2020-03-25
11 Magnus Westerlund IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2020-03-25
11 Magnus Westerlund Ballot has been issued
2020-03-25
11 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund
2020-03-25
11 Magnus Westerlund Created "Approve" ballot
2020-03-25
11 Magnus Westerlund Ballot writeup was changed
2020-03-05
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-03-05
11 Reese Enghardt New version available: draft-ietf-taps-transport-security-11.txt
2020-03-05
11 (System) New version approved
2020-03-05
11 (System) Request for posting confirmation emailed to previous authors: Kyle Rose , Tommy Pauly , taps-chairs@ietf.org, Theresa Enghardt , Colin Perkins , Christopher Wood
2020-03-05
11 Reese Enghardt Uploaded new revision
2020-01-13
10 Magnus Westerlund IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead::Point Raised - writeup needed
2020-01-02
10 Magnus Westerlund WG still have last call issues and comments to resolve that will require a new version before being addressed.
2020-01-02
10 Magnus Westerlund IESG state changed to Waiting for AD Go-Ahead::Point Raised - writeup needed from Waiting for AD Go-Ahead::AD Followup
2019-11-17
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-11-17
10 Tommy Pauly New version available: draft-ietf-taps-transport-security-10.txt
2019-11-17
10 (System) New version accepted (logged-in submitter: Tommy Pauly)
2019-11-17
10 Tommy Pauly Uploaded new revision
2019-10-24
09 Jean Mahoney Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour. Submission of review completed at an earlier date.
2019-10-24
09 Magnus Westerlund
IETF last call reviews by Eric Rescorla and Christian Huitema points to the significant question of architectural implications of where the security functions resides in …
IETF last call reviews by Eric Rescorla and Christian Huitema points to the significant question of architectural implications of where the security functions resides in the stacks, and the potential limitation of possible deployment models in the context of TAPS. Have requested discussion of this topic before going ahead with IESG evaluation.
2019-10-24
09 Magnus Westerlund IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for Writeup
2019-10-24
09 Magnus Westerlund Ballot writeup was changed
2019-10-24
09 Magnus Westerlund Changed consensus to Yes from Unknown
2019-10-18
09 Jean Mahoney Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2019-10-18
09 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Sheng Jiang was marked no-response
2019-10-18
09 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-10-16
09 Paul Wouters Request for Last Call review by SECDIR Completed: Ready. Reviewer: Paul Wouters. Sent review to list.
2019-10-15
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sheng Jiang
2019-10-15
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sheng Jiang
2019-10-10
09 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-10-10
09 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-taps-transport-security-09, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-taps-transport-security-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-10-10
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2019-10-10
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2019-10-04
09 Philipp Tiesel
1. Summary
The document shepherd is Philipp S. Tiesel.
The responsible Area Director is Magnus Westerlund.

The document provides a survey of commonly used or …
1. Summary
The document shepherd is Philipp S. Tiesel.
The responsible Area Director is Magnus Westerlund.

The 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. It is intended to guide
APIs that offer both transport services and transport security
services.
Section 3 and 4 complements RFC 8095 in its efforts to catalog
transport services by describing the transport services provided
by security protocols. 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 Transport Services
system may need to support.
Sections 4 and 5 complement "draft-ietf-taps-minset": They extend the
minimum feature set for a TAPS system with transport security services
and describe the interfaces required to add security protocols to a
TAPS system.

The intended publication type is Informational, as the document
contains a survey of existing security protocols. Its intended audience
are implementors of transport services APIs based on TAPS agenda
item 3 and 4 that use security protocols and people generally
interested in the features security protocols provide.

2. Review and Consensus

The document was started by a small number of people, but the need for
it has strong consensus. Adopting it took some time as it required
re-chartering the WG to allow summarising security protocols and
defining a set of security-related transport services. The document was
actively discussed on the mailing list and received a considerable
number of reviews, updates, and improvements throughout this process.

An early Secdir review raised concerns against including non-IETF
protocols without stable specification, e.g., Wiregugrd, CurveCP, and
MinimalT, while not describing other popular IETF protocols. The
authors decided to keep these protocols in the document as there have
unique features they wanted to include, and to add the protocols
requested by the Secdir review. The informal criteria for inclusion of
protocols were clarified by the authors established as any new protocol
must either add a new transport feature or be extremely popular. The
wording was adapted to address the concerns.

The WG last call received considerable feedback without major issues
being raised. Last-minute issues raised by the shepherd have been
corrected.

3. Intellectual Property

As this document introduces no new technologies or APIs beyond those
already published, I see no IPR issues.

4. Other Points

There are no normative downward references and no IANA considerations.

The document references two RFCs that have been obsoleted:
- RFC 2385 (TCP MD5): This reference is correct as the mechanism
  still exists and is actively used and, therefore, relevant for this document.
- RFC 5246 (TLS 1.2): This reference is necessary, as the document
  discusses differences between TLS 1.2 and TLS 1.3 (RFC 8446)
  and, therefore, needs to reference the obsolete version.
2019-10-04
09 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2019-10-04
09 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2019-10-04
09 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-10-04
09 Amy Vezza
The following Last Call announcement was sent out (ends 2019-10-18):

From: The IESG
To: IETF-Announce
CC: magnus.westerlund@ericsson.com, philipp@tiesel.net, taps-chairs@ietf.org, Philipp Tiesel , …
The following Last Call announcement was sent out (ends 2019-10-18):

From: The IESG
To: IETF-Announce
CC: magnus.westerlund@ericsson.com, philipp@tiesel.net, taps-chairs@ietf.org, Philipp Tiesel , draft-ietf-taps-transport-security@ietf.org, taps@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Survey of Transport Security Protocols) to Informational RFC


The IESG has received a request from the Transport Services WG (taps) to
consider the following document: - 'A Survey of Transport Security Protocols'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-10-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

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 by describing the
  interfaces required to add security protocols.  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 Transport
  Services system may need to support.  Moreover, this document defines
  a minimal set of security features that a secure transport system
  should provide.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-10-04
09 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-10-04
09 Magnus Westerlund Last call was requested
2019-10-04
09 Magnus Westerlund Last call announcement was generated
2019-10-04
09 Magnus Westerlund Ballot approval text was generated
2019-10-04
09 Magnus Westerlund Ballot writeup was generated
2019-10-04
09 Magnus Westerlund IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-09-28
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-09-28
09 Christopher Wood New version available: draft-ietf-taps-transport-security-09.txt
2019-09-28
09 (System) New version accepted (logged-in submitter: Christopher Wood)
2019-09-28
09 Christopher Wood Uploaded new revision
2019-09-26
08 Magnus Westerlund https://mailarchive.ietf.org/arch/msg/taps/_mhRJSAQAx_l-y2Cl7YtRpp7j4s
2019-09-26
08 Magnus Westerlund IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-08-28
08 Magnus Westerlund IESG state changed to AD Evaluation from Publication Requested
2019-08-09
08 Aaron Falk
1. Summary
The document shepherd is Philipp S. Tiesel.
The responsible Area Director is Magnus Westerlund.

The document provides a survey of commonly used or …
1. Summary
The document shepherd is Philipp S. Tiesel.
The responsible Area Director is Magnus Westerlund.

The 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. It is intended to guide
APIs that offer both transport services and transport security
services.
Section 3 and 4 complements RFC 8095 in its efforts to catalog
transport services by describing the transport services provided
by security protocols. 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 Transport Services
system may need to support.
Sections 4 and 5 complement "draft-ietf-taps-minset": They extend the
minimum feature set for a TAPS system with transport security services
and describe the interfaces required to add security protocols to a
TAPS system.

The intended publication type is Informational, as the document
contains a survey of existing security protocols. Its intended audience
are implementors of transport services APIs based on TAPS agenda
item 3 and 4 that use security protocols and people generally
interested in the features security protocols provide.

2. Review and Consensus

The document was started by a small number of people, but the need for
it has strong consensus. Adopting it took some time as it required
re-chartering the WG to allow summarising security protocols and
defining a set of security-related transport services. The document was
actively discussed on the mailing list and received a considerable
number of reviews, updates, and improvements throughout this process.

An early Secdir review raised concerns against including non-IETF
protocols without stable specification, e.g., Wiregugrd, CurveCP, and
MinimalT, while not describing other popular IETF protocols. The
authors decided to keep these protocols in the document as there have
unique features they wanted to include, and to add the protocols
requested by the Secdir review. The informal criteria for inclusion of
protocols were clarified by the authors established as any new protocol
must either add a new transport feature or be extremely popular. The
wording was adapted to address the concerns.

The WG last call received considerable feedback without major issues
being raised. Last-minute issues raised by the shepherd have been
corrected.

3. Intellectual Property

As this document introduces no new technologies or APIs beyond those
already published, I see no IPR issues.

4. Other Points

There are no normative downward references and no IANA considerations.
2019-08-09
08 Aaron Falk Responsible AD changed to Magnus Westerlund
2019-08-09
08 Aaron Falk IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2019-08-09
08 Aaron Falk IESG state changed to Publication Requested from I-D Exists
2019-08-09
08 Aaron Falk IESG process started in state Publication Requested
2019-08-08
08 Philipp Tiesel
1. Summary
The document shepherd is Philipp S. Tiesel.
The responsible Area Director is Magnus Westerlund.

The document provides a survey of commonly used or …
1. Summary
The document shepherd is Philipp S. Tiesel.
The responsible Area Director is Magnus Westerlund.

The 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. It is intended to guide
APIs that offer both transport services and transport security
services.
Section 3 and 4 complements RFC 8095 in its efforts to catalog
transport services by describing the transport services provided
by security protocols. 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 Transport Services
system may need to support.
Sections 4 and 5 complement "draft-ietf-taps-minset": They extend the
minimum feature set for a TAPS system with transport security services
and describe the interfaces required to add security protocols to a
TAPS system.

The intended publication type is Informational, as the document
contains a survey of existing security protocols. Its intended audience
are implementors of transport services APIs based on TAPS agenda
item 3 and 4 that use security protocols and people generally
interested in the features security protocols provide.

2. Review and Consensus

The document was started by a small number of people, but the need for
it has strong consensus. Adopting it took some time as it required
re-chartering the WG to allow summarising security protocols and
defining a set of security-related transport services. The document was
actively discussed on the mailing list and received a considerable
number of reviews, updates, and improvements throughout this process.

An early Secdir review raised concerns against including non-IETF
protocols without stable specification, e.g., Wiregugrd, CurveCP, and
MinimalT, while not describing other popular IETF protocols. The
authors decided to keep these protocols in the document as there have
unique features they wanted to include, and to add the protocols
requested by the Secdir review. The informal criteria for inclusion of
protocols were clarified by the authors established as any new protocol
must either add a new transport feature or be extremely popular. The
wording was adapted to address the concerns.

The WG last call received considerable feedback without major issues
being raised. Last-minute issues raised by the shepherd have been
corrected.

3. Intellectual Property

As this document introduces no new technologies or APIs beyond those
already published, I see no IPR issues.

4. Other Points

There are no normative downward references and no IANA considerations.
2019-08-08
08 Philipp Tiesel
1. Summary
The document shepherd is Philipp S. Tiesel. The responsible Area Director is Magnus Westerlund.

The document provides a survey of commonly used or …
1. Summary
The document shepherd is Philipp S. Tiesel. The responsible Area Director is Magnus Westerlund.

The 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. It is intended to guide
APIs that offer both transport services and transport security
services.
Section 3 and 4 complements RFC 8095 in its efforts to catalog
transport services by describing the transport services provided
by security protocols. 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 Transport Services
system may need to support.
Sections 4 and 5 complement "draft-ietf-taps-minset": They extend the
minimum feature set for a TAPS system with transport security services
and describe the interfaces required to add security protocols to a
TAPS system.

The intended publication type is Informational, as the document
contains a survey of existing security protocols. Its intended audience
are implementors of transport services APIs based on TAPS agenda
item 3 and 4 that use security protocols and people generally
interested in the features security protocols provide.

2. Review and Consensus

The document was started by a small number of people, but the need for
it has strong consensus. Adopting it took some time as it required
re-chartering the WG to allow summarising security protocols and
defining a set of security-related transport services. The document was
actively discussed on the mailing list and received a considerable
number of reviews, updates, and improvements throughout this process.

An early Secdir review raised concerns against including non-IETF
protocols without stable specification, e.g., Wiregugrd, CurveCP, and
MinimalT, while not describing other popular IETF protocols. The
authors decided to keep these protocols in the document as there have
unique features they wanted to include, and to add the protocols
requested by the Secdir review. The informal criteria for inclusion of
protocols were clarified by the authors established as any new protocol
must either add a new transport feature or be extremely popular. The
wording was adapted to address the concerns.

The WG last call received considerable feedback without major issues
being raised. Last-minute issues raised by the shepherd have been
corrected.

3. Intellectual Property

As this document introduces no new technologies or APIs beyond those
already published, I see no IPR issues.

4. Other Points

There are no normative downward references and no IANA considerations.
2019-08-08
08 Philipp Tiesel
1. Summary
The document shepherd is Philipp S. Tiesel. The responsible Area Director is Magnus Westerlund.

The document provides a survey of commonly used or …
1. Summary
The document shepherd is Philipp S. Tiesel. The responsible Area Director is Magnus Westerlund.

The 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. It is intended to guide
APIs that offer both transport services and transport security
services.
Section 3 and 4 complements RFC 8095 in its efforts to catalog
transport services by describing the transport services provided
by security protocols. 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 Transport Services
system may need to support.
Sections 4 and 5 complement "draft-ietf-taps-minset": They extend the
minimum feature set for a TAPS system with transport security services
and describe the interfaces required to add security protocols to a
TAPS system.

The intended publication type is Informational, as the document
contains a survey of existing security protocols. Its intended audience
are implementors of transport services APIs based on TAPS agenda
item 3 and 4 that use security protocols and people generally
interested in the features security protocols provide.

2. Review and Consensus

The document was started by a small number of people, but the need for
it has strong consensus. Adopting it took some time as it required
re-chartering the WG to allow summarising security protocols and
defining a set of security-related transport services. The document was
actively discussed on the mailing list and received a considerable
number of reviews, updates, and improvements throughout this process.

An early Secdir review raised concerns against including non-IETF
protocols without stable specification, e.g., Wiregugrd, CurveCP, and
MinimalT, while not describing other popular IETF protocols. The
authors decided to keep these protocols in the document as there have
unique features they wanted to include, and to add the protocols
requested by the Secdir review. The informal criteria for inclusion of
protocols were clarified by the authors established as any new protocol
must either add a new transport feature or be extremely popular. The
wording was adapted to address the concerns.

The WG last call received considerable feedback without major issues
being raised. Last-minute issues raised by the shepherd have been
corrected.

3. Intellectual Property

As this document introduces no new technologies or APIs beyond those
already published, I see no IPR issues.

4. Other Points

There are no normative downward references and no IANA considerations.
2019-08-08
08 Philipp Tiesel
1. Summary
The document shepherd is Philipp S. Tiesel. The responsible Area Director is Magnus Westerlund.

The document provides a survey of commonly used or …
1. Summary
The document shepherd is Philipp S. Tiesel. The responsible Area Director is Magnus Westerlund.

The 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. Section 3 and 4 complements RFC 8095 in its efforts to catalog transport services by describing the transport services provided by security protocols.
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 Transport Services system may need to support.
Sections 4 and 5 complement "draft-ietf-taps-minset": They extend the minimum feature set for a TAPS system with security features and describe the interfaces required to add security protocols to a TAPS system.

The intended publication type is Informational, as the document contains a survey of existing security protocols. Its intended audience are implementors of transport services based on TAPS agenda item 3 and 4 that use security protocols and people generally interested in the features security protocols provide.

2. Review and Consensus

The document was started by a small number of people, but the need for it has strong consensus. Adopting it took some time as it required re-chartering the WG to allow summarising security protocols and defining a set of security-related transport services. The document was actively discussed on the mailing list and received a considerable number of reviews, updates, and improvements throughout this process.
An early Secdir review raised concerns against including non-IETF protocols without stable specification, e.g., Wiregugrd, CurveCP, and MinimalT, while not describing other popular IETF protocols. The authors decided to keep these protocols in the document as there have unique features they wanted to include, and to add the protocols requested by the Secdir review. The informal criteria for inclusion of protocols were clarified by the authors established as any new protocol must either add a new transport feature or be extremely popular. The wording was adapted to address the concerns.
The WG last call received considerable feedback without major issues being raised. Last-minute issues raised by the shepherd have been corrected.

3. Intellectual Property

As this document introduces no new technologies or APIs beyond those already published, I see no IPR issues.

4. Other Points

There are no normative downward references and no IANA considerations.
2019-08-07
08 Tommy Pauly New version available: draft-ietf-taps-transport-security-08.txt
2019-08-07
08 (System) New version approved
2019-08-07
08 (System) Request for posting confirmation emailed to previous authors: Colin Perkins , Kyle Rose , Theresa Enghardt , Tommy Pauly , Christopher Wood
2019-08-07
08 Tommy Pauly Uploaded new revision
2019-07-24
07 Tommy Pauly New version available: draft-ietf-taps-transport-security-07.txt
2019-07-24
07 (System) New version approved
2019-07-24
07 (System) Request for posting confirmation emailed to previous authors: Colin Perkins , Kyle Rose , Theresa Enghardt , Tommy Pauly , Christopher Wood
2019-07-24
07 Tommy Pauly Uploaded new revision
2019-07-23
06 Aaron Falk Notification list changed to Philipp Tiesel <philipp@tiesel.net>
2019-07-23
06 Aaron Falk Document shepherd changed to Philipp S. Tiesel
2019-07-01
06 Aaron Falk Working group commentary on last call was limited but all positive.  Moving ahead with request for publication once a shepherd can be identified.
2019-07-01
06 Aaron Falk IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2019-04-10
06 Aaron Falk Changed document URLs from:

[]

to:

repository https://github.com/ietf-tapswg/draft-ietf-taps-transport-security
2019-04-10
06 Aaron Falk
WGLC initiated 4/10/19.  As discussed at the TAPS meeting in Prague, the plan is to last call the document and then hold it to publish …
WGLC initiated 4/10/19.  As discussed at the TAPS meeting in Prague, the plan is to last call the document and then hold it to publish in a cluster with the architecture, interface, and implementation docs.
2019-04-10
06 Aaron Falk IETF WG state changed to In WG Last Call from WG Document
2019-03-20
06 Aaron Falk Added to session: IETF-104: taps  Fri-1050
2019-03-11
06 Christopher Wood New version available: draft-ietf-taps-transport-security-06.txt
2019-03-11
06 (System) New version approved
2019-03-11
06 (System) Request for posting confirmation emailed to previous authors: Colin Perkins , Kyle Rose , Theresa Enghardt , Tommy Pauly , Christopher Wood
2019-03-11
06 Christopher Wood Uploaded new revision
2019-02-27
05 Paul Wouters Request for Early review by SECDIR Completed: Ready. Reviewer: Paul Wouters.
2019-02-26
05 Christopher Wood New version available: draft-ietf-taps-transport-security-05.txt
2019-02-26
05 (System) New version approved
2019-02-26
05 (System) Request for posting confirmation emailed to previous authors: Colin Perkins , Kyle Rose , taps-chairs@ietf.org, Christopher Wood , Tommy Pauly
2019-02-26
05 Christopher Wood Uploaded new revision
2018-11-09
04 Tero Kivinen Request for Early review by SECDIR is assigned to Paul Wouters
2018-11-09
04 Tero Kivinen Request for Early review by SECDIR is assigned to Paul Wouters
2018-11-04
04 Aaron Falk Requested Early review by SECDIR
2018-11-04
04 Christopher Wood New version available: draft-ietf-taps-transport-security-04.txt
2018-11-04
04 (System) New version approved
2018-11-04
04 (System) Request for posting confirmation emailed to previous authors: Colin Perkins , Kyle Rose , Christopher Wood , Tommy Pauly
2018-11-04
04 Christopher Wood Uploaded new revision
2018-10-22
03 Aaron Falk Added to session: IETF-103: taps  Wed-1540
2018-10-22
03 Christopher Wood New version available: draft-ietf-taps-transport-security-03.txt
2018-10-22
03 (System) New version approved
2018-10-22
03 (System) Request for posting confirmation emailed to previous authors: Colin Perkins , Kyle Rose , Christopher Wood , Tommy Pauly
2018-10-22
03 Christopher Wood Uploaded new revision
2018-07-17
02 Aaron Falk Intended Status changed to Informational from None
2018-07-12
02 Aaron Falk Added to session: IETF-102: taps  Tue-1550
2018-06-30
02 Tommy Pauly New version available: draft-ietf-taps-transport-security-02.txt
2018-06-30
02 (System) New version approved
2018-06-30
02 (System) Request for posting confirmation emailed to previous authors: Colin Perkins , Kyle Rose , Christopher Wood , Tommy Pauly
2018-06-30
02 Tommy Pauly Uploaded new revision
2018-05-15
01 Aaron Falk Added to session: interim-2018-taps-01
2018-05-11
01 Christopher Wood New version available: draft-ietf-taps-transport-security-01.txt
2018-05-11
01 (System) New version approved
2018-05-11
01 (System) Request for posting confirmation emailed to previous authors: Colin Perkins , Kyle Rose , Christopher Wood , Tommy Pauly
2018-05-11
01 Christopher Wood Uploaded new revision
2018-03-26
00 Christopher Wood New version available: draft-ietf-taps-transport-security-00.txt
2018-03-26
00 (System) WG -00 approved
2018-03-23
00 Christopher Wood Set submitter to ""Christopher A. Wood" ", replaces to (none) and sent approval email to group chairs: taps-chairs@ietf.org
2018-03-23
00 Christopher Wood Uploaded new revision