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 |