Cryptographic Protection of TCP Streams (tcpcrypt)
draft-ietf-tcpinc-tcpcrypt-15

Request for posting confirmation emailed to previous authors: Quinn Slack , tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley

Request for posting confirmation emailed to previous authors: Quinn Slack , tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley

Request for posting confirmation emailed to previous authors: Quinn Slack , tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley

Request for posting confirmation emailed to previous authors: Quinn Slack , tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley

Request for posting confirmation emailed to previous authors: Quinn Slack , tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley

Request for posting confirmation emailed to previous authors: Quinn Slack , tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley

[Ballot comment]
Thank you for the discussion and agreement on the two points for additional (SHOULD) algorithms and your work on this draft and experiment.

I support Eric's discuss.

I'd also like to see Barry's SecDir review and the Steve Kent review he referenced discussed and resolved.
Barry's SecDir review:
https://mailarchive.ietf.org/arch/msg/tcpinc/tTSvtVqM_cQ5-vaZ1ivrgkFC_9E

[Ballot comment]
Thank you for the discussion and agreement on the two points for additional (SHOULD) algorithms and your work on this draft and experiment.

I support Eric's discuss.

[Ballot comment]
In section 3.3, the last bullet: Why are the SHOULDs not MUSTs? Do you envision times where it might make sense not refresh an ephemeral public key, or write one to persistent storage?

[Ballot discuss]
https://mozphab-ietf.devsvcdev.mozaws.net/D3970

  2^64 bytes in the underlying TCP datastream (which would cause the
  "offset" field to wrap) before re-keying.
 
In TLS and other WGs, we have adopted the practice of
salting the nonce with a secret per-connection value to avoid
large-scale surveillance attacks. Why did you opt to use a weaker
construction. See:
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#security-record-layer
and https://eprint.iacr.org/2016/564.


  FIN flag set, it MUST immediately send a frame (with empty
  application data if necessary) with "rekey = 1".
 
I don't think that the algorithm in this section
necessarily works properly, because you have to handle rekeys in
sequence:

Frame 1 [0:999]
Frame 2 [1000:1999, rekey=1]
Frame 3 [2000:2999, rekey=1]

Now what happens if the frames are re-ordered so you get Frame 3 and
then Frame 2. You will try to decrypt Frame 3 with generation 2 and
Frame 2 with generation 3, neither of which will work (though you
might be able to interpret the text loosely to have you try to decrypt
Frame 2 with generation 2). Note that if you were to resequence before
processing, this wouldn't happen.

At minimum I think some clarification is needed here.



Given that you are allowing P-256 and point reuse, you
should be requiring point validation. See:
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.4.2.8.2
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#elliptic-curve-diffie-hellman

You should probably also be requiring Curve25519 output validation.


You still seem to need to specify an MTI symmetric algorithm.

[Ballot comment]

The design of session resumption here essentially precludes doing
tcpcrypt resumption across servers (as one does with TLS) because you
need extremely tight control of ss[i] or you have catastrophic
results. Was this a deliberate choice by the WG?


  suboption containing the TEP identifier and "v = 0".  In order to
  propose session resumption (described further below) with a
  particular TEP, a host sends a variable-length suboption containing

It would be clearer if you explained resumption here.



          PRK = Extract(N_A, eno-transcript | Init1 | Init2 | ES)
What is the rationale for providing N_A as the salt to HKDF-Extract, given that you also supply N_A in the Init1 message?



  session resumption such that a given pre-session key "ss[0]" is only
  used for either passive or active opens at the same host, not both.
This seems like it probably needs some more emphasis, as failure to follow this instruction results in GCM compromise.

It would probably be useful to explain why you opted for this design rather than having nonces, which would remove the need for such strict ss[i] management. I assume the reason is that you want to save the round trip?




  connection; but if it aborts, the implementation MUST raise an error
  condition distinct from the end-of-file condition.
 
Note that this interacts badly with the rekey issue I raise below.






  format", and MUST accept values encoded in "compressed",
  "uncompressed" or "hybrid" formats.
 
Why are you allowing multiple formats here? Generally, if you're going to encourage compressed, you want to just require it.

[Ballot comment]
Nothing against the publication of this document but ... as for any experimental RFCs, we must describe the criteria for a successful experiment (evaluation)?

[Ballot comment]
Thanks for a well-written document. I have some suggestions for improvement (two minor, and one significant).

This document has several references to tables that are quite distant from the table being referenced. It might be useful to readers if these were phrased something like "Table 4 in section 7," so they know where to go looking for the table.

Section 3.5 says:

  If an active opener receives a resumption suboption for a particular
  TEP and the received identifier-half does not match the "resume[i]"
  value whose other half it previously sent in a resumption suboption
  for the same TEP, it MUST ignore that suboption.  In the typical case
  that this was the only ENO suboption received, this means the host
  MUST disable TCP-ENO and tcpcrypt: that is, it MUST NOT send any more
  ENO options and MUST NOT encrypt the connection.

I think the text here would benefit from pointing out that the client MUST NOT attempt to resume a session with this host for the next TCP connection attempt.

____

Section 3.6 stipulates:

  When a frame is received, tcpcrypt reconstructs the associated data
  and frame nonce values (the former contains only data sent in the
  clear, and the latter is implicit in the TCP stream), and provides
  these and the ciphertext value to the the AEAD decryption operation.
  The output of this operation is either a plaintext value "P" or the
  special symbol FAIL.  In the latter case, the implementation MUST
  either drop the TCP segment(s) containing the frame or abort the
  connection; but if it aborts, the implementation MUST raise an error
  condition distinct from the end-of-file condition.

In the text above, the choice to "drop the TCP segment(s)" seems a little underspecified, and both ways that I can interpret it are problematic.

In one interpretation, the TCP stack acts as if those packets were never received, and so they are never acknowledged. Since retransmissions will contain the same contents and also fail to decrypt, this is basically just going to cause a connection failure upon expiration of the retransmission timer -- in which case an immediate failure is clearly preferable.

The other interpretation is that the TCP packet is processed as received, but that all of the data that could not be decrypted is elided from the stream of bytes provided to the receiving application. This is also a problem, since many applications rely on the in-order delivery aspects of TCP. The prospect that a sender could provide "Message A", "Message B", and then"Message C" to its TCP socket and the receiver only get "Message A" followed immediately by "Message C" is not something that applications will generally be capable of handling. As before, a connection reset would be preferable to violating the in-order delivery guarantees of TCP.

Unless my analysis here is confused, I think this text needs to be changed to conclude:

  In the latter case, the implementation MUST
  abort the connection and raise an error
  condition distinct from the end-of-file condition.

[Ballot comment]
I really like this draft, and I can understand it fairly well. I do have some questions to go along with my Yes ballot.

This SHOULD NOT

  o  "PK_A", "PK_B": ephemeral public keys for hosts A and B,
      respectively.  These, as well as their corresponding private keys,
      are short-lived values that SHOULD be refreshed periodically.  The
      private keys SHOULD NOT ever be written to persistent storage.

is just begging for some justification as to why this is important enough to be a SHOULD NOT, and not important enough to be a MUST NOT. Could you give an example of a reason why this would be a good idea?

It's likely that everyone but me knows why

                resume[i] = CPRF(ss[i], CONST_RESUME, 18)

is "18" and not some other integer, but there's no explanation or reference that I could find explaining why.

It would be helpful to explain why

  In a particular SYN segment, a host SHOULD NOT send more than one
  resumption suboption,

is a SHOULD NOT, since it's allowed, so doing so must have some purpose.

This

  A host SHOULD NOT initiate more than one concurrent re-key operation
  if it has no data to send; that is, it should not initiate re-keying
  with an empty encryption frame more than once while its record of the
  remote generation number is less than its own.

is allowed - could you explain why a host would need to violate that SHOULD NOT?

Just for my benefit - Section 8.3 explains why ECDHE using Curve25519 has been chosen as MTI, but also explains why ECDHE using P-256 has not been chosen as a second MTI. Is the intention to discourage use of ECDHE using P-256 at all, based on the concerns expressed about making it MTI?

Also for my benefit, but somewhat more worrying - is the working group fairly confident that a specifying second MTI key management scheme will be possible at some point, that does not trip over the problems described in [nist-ecc] and can be implemented in kernels, or is conforming to the guidance in [RFC7696] going to be problematic? I see Mirja mentioned SEC discussions about only one MTI key management mechanism being chosen now, but my question is a little different - I'm asking if the situation is likely to improve anytime soon.

[Ballot comment]
Based on comments received during IETF last cast, the latest version of this document (-08) now recommends a different AEAD algorithm as MIT. There is still some on-going  discussion with the SEC ADs if only one MIT is acceptable. There is consensus in the working group to move forward with only one but they are also open for other recommendations as feedback from the IESG evaluation.

Request for posting confirmation emailed to previous authors: Quinn Slack , tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley

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

The IANA Services Operator has completed its review of draft-ietf-tcpinc-tcpcrypt-07. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

We understand that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: [ I-D.ietf-tcpinc-tcpeno ]

First, in a new registry created upon the approval of [ I-D.ietf-tcpinc-tcpeno ] called the TCP encryption protocol identifiers registry, four new values are to be added to the new registry. The new registry is to be located on the Transmission Control Protocol (TCP) Parameters registry page located at:

https://www.iana.org/assignments/tcp-parameters/

The four values to be added to the registry are as follows:

+-------+---------------------------+---------------+
| Value | Meaning | Reference |
+-------+---------------------------+---------------+
| 0x21 | TCPCRYPT_ECDHE_P256 | [ RFC-to-be ] |
| 0x22 | TCPCRYPT_ECDHE_P521 | [ RFC-to-be ] |
| 0x23 | TCPCRYPT_ECDHE_Curve25519 | [ RFC-to-be ] |
| 0x24 | TCPCRYPT_ECDHE_Curve448 | [ RFC-to-be ] |
+-------+---------------------------+---------------+

Second, a new registry is to be created called the tcpcrypt AEAD Algorithm registry. The new registry is to be located on the Transmission Control Protocol (TCP) Parameters registry page located at:

https://www.iana.org/assignments/tcp-parameters/

The registry is to be maintained via RFC Required as defined by [ RFC 8126 ].

There are three initial entries in the new registry as follows:

+-------+------------------------+------------+---------------+
| Value | AEAD Algorithm | Key Length | Reference |
+-------+------------------------+------------+---------------+
| 0x01 | AEAD_AES_128_GCM | 16 bytes | [ RFC-to-be ] |
| 0x02 | AEAD_AES_256_GCM | 32 bytes | [ RFC-to-be ] |
| 0x10 | AEAD_CHACHA20_POLY1305 | 32 bytes | [ RFC-to-be ] |
+-------+------------------------+------------+---------------+

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-19):

From: The IESG
To: IETF-Announce
CC: tcpinc@ietf.org, krose@krose.org, tcpinc-chairs@ietf.org, ietf@kuehlewind.net, Kyle Rose , draft-ietf-tcpinc-tcpcrypt@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Cryptographic protection of TCP Streams (tcpcrypt)) to Experimental RFC


The IESG has received a request from the TCP Increased Security WG (tcpinc)
to consider the following document: - 'Cryptographic protection of TCP
Streams (tcpcrypt)'
  as Experimental 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 2017-10-19. 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 specifies tcpcrypt, a TCP encryption protocol designed
  for use in conjunction with the TCP Encryption Negotiation Option
  (TCP-ENO).  Tcpcrypt coexists with middleboxes by tolerating
  resegmentation, NATs, and other manipulations of the TCP header.  The
  protocol is self-contained and specifically tailored to TCP
  implementations, which often reside in kernels or other environments
  in which large external software dependencies can be undesirable.
  Because the size of TCP options is limited, the protocol requires one
  additional one-way message latency to perform key exchange before
  application data may be transmitted.  However, this cost can be
  avoided between two hosts that have recently established a previous
  tcpcrypt connection.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/ballot/


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

Request for posting confirmation emailed to previous authors: Quinn Slack , tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley

Cryptographic protection of TCP Streams (tcpcrypt)
draft-ietf-tcpinc-tcpcrypt-06

1. Summary

Document Shepherd: Kyle Rose
Responsible AD: Mirja Kühlewind

  This document specifies tcpcrypt, a TCP encryption protocol designed
  for use in conjunction with the TCP Encryption Negotiation Option
  (TCP-ENO) [I-D.ietf-tcpinc-tcpeno].  Tcpcrypt coexists with
  middleboxes by tolerating resegmentation, NATs, and other
  manipulations of the TCP header.  The protocol is self-contained and
  specifically tailored to TCP implementations, which often reside in
  kernels or other environments in which large external software
  dependencies can be undesirable.  Because the size of TCP options is
  limited, the protocol requires one additional one-way message latency
  to perform key exchange before application data may be transmitted.
  However, this cost can be avoided between two hosts that have
  recently established a previous tcpcrypt connection.

The WG has requested Experimental status because this draft specifies a new
protocol for which implementation and usage experience is desired before
producing a proposed standard.

2. Review and Consensus

In response to concerns about pervasive surveillance, the tcpinc WG was formed
in 2014 to produce a TCP extension that provides unauthenticated
(opportunistic) encryption of TCP streams. The goal is universal encryption of
TCP streams, increasing the burden of pervasive surveillance from passive
dragnet attacks to per-connection active (e.g., man-in-the-middle) attacks.

An inability to achieve consensus on a single approach best characterizes the
first year and a half of the WG's existence. There were two competing
proposals, the Stanford-led tcpcrypt and a profile of TLS with authentication
removed (tcpinc-use-TLS). As both tcpcrypt and TLS are independent and
fully-realized protocols, this mooted any collaboration or compromise. This
inability to achieve consensus damaged the WG, as parties looking for a
solution in this space grew weary of the lack of progress. Many who initially
expressed interest in working on independent implementations lost interest and
moved on to other work.

The logjam was successfully broken by three WG actions in the second half of
2015. The first was that the TCP extension functionality of tcpcrypt was split
off into a separate proposal called TCP-ENO (Encryption Negotiation Option).
This extension notably has the ability to negotiate multiple TCP stream
encryption protocols, allowing potentially for runtime negotiation of either
tcpcrypt or tcpinc-use-TLS (or indeed any other future encryption protocol).

The second action was initiated by the chairs. After the Transport AD changed
the WG chairs in July 2015, the new chairs made a call for adoption of both
tcpcrypt and tcpinc-use-TLS. ENO enabled this action by making it credible that
both protocols could be concurrently deployed.

The logjam was finally broken by competing demands for the TLS community,
including for the editor of the tcpinc-use-TLS draft, especially for completion
of TLS 1.3 work in early 2016. This was discussed in the tcpinc WG, and the
resulting rough consensus of the WG was that the appropriate course of action
was to complete work on tcpcrypt and TCP-ENO as soon as possible, making sure
that ENO could eventually support a TLS profile.

Following this decision, rough consensus was achieved fairly rapidly, with only
minor tweaks to the protocol since March 2016. Mailing list traffic has been
very quiet since September 2016, and no tcpinc session was held at IETF 98 in
Chicago.

Expert reviews were conducted by Yoav Nir and Jana Iyengar, with important
additional feedback from mailing list members of CFRG. No fundamental blocking
issues have been revealed through review. The chairs would like an additional
review by the Security Area Directorate.

There is only one current implementation of tcpcrypt, that being the reference
implementation by the Stanford team. At least one other implementation effort
is in progress. The WG chairs believe that a reliable implementation
distributed as part of a major operating system is the best approach to
rekindling interest in this project and for encouraging the development of
additional interoperating implementations.

3. Intellectual Property

Each draft author has stated his/her direct, personal knowledge that any IPR
related to this document has already been disclosed, in conformance with BCPs
78 and 79.

4. Other Points

The original implementation of tcpcrypt squatted on TCP option kind 69, which
caused some controversy and animated discussion on the mailing list. After some
negotiation with Joe Touch, it was decided that tcpcrypt would be willing to
bear the cost of this decision by requesting the same option for assignment by
IANA.

Tcpcrypt requires the addition of an IANA registry with expert review for
"tcpcrypt AEAD parameter", the initial values for which are listed in section
7: this is code point allocation for the AEAD algorithm used for bulk
encryption, symmetric authentication, and integrity protection. Expert
reviewers for this registry should understand the implications of individual
AEAD encryption modes and how they relate to the requirements of both TCP-ENO
and tcpcrypt.

Minimum criteria for a move from Experimental to Proposed Standard status
should include substantive deployment experience spanning multiple
implementations and networks and a BCP document describing deployment
challenges and mitigations, especially with respect to successfully transiting
middle boxes.

Cryptographic protection of TCP Streams (tcpcrypt)
draft-ietf-tcpinc-tcpcrypt-06

1. Summary

Document Shepherd: Kyle Rose
Responsible AD: Mirja Kühlewind

  This document specifies tcpcrypt, a TCP encryption protocol designed
  for use in conjunction with the TCP Encryption Negotiation Option
  (TCP-ENO) [I-D.ietf-tcpinc-tcpeno].  Tcpcrypt coexists with
  middleboxes by tolerating resegmentation, NATs, and other
  manipulations of the TCP header.  The protocol is self-contained and
  specifically tailored to TCP implementations, which often reside in
  kernels or other environments in which large external software
  dependencies can be undesirable.  Because the size of TCP options is
  limited, the protocol requires one additional one-way message latency
  to perform key exchange before application data may be transmitted.
  However, this cost can be avoided between two hosts that have
  recently established a previous tcpcrypt connection.

The WG has requested Experimental status because this draft specifies a new
protocol for which implementation and usage experience is desired before
producing a proposed standard.

2. Review and Consensus

In response to concerns about pervasive surveillance, the tcpinc WG was formed
in 2014 to produce a TCP extension that provides unauthenticated
(opportunistic) encryption of TCP streams. The goal is universal encryption of
TCP streams, increasing the burden of pervasive surveillance from passive
dragnet attacks to per-connection active (e.g., man-in-the-middle) attacks.

An inability to achieve consensus on a single approach best characterizes the
first year and a half of the WG's existence. There were two competing
proposals, the Stanford-led tcpcrypt and a profile of TLS with authentication
removed (tcpinc-use-TLS). As both tcpcrypt and TLS are independent and
fully-realized protocols, this mooted any collaboration or compromise. This
inability to achieve consensus damaged the WG, as parties looking for a
solution in this space grew weary of the lack of progress. Many who initially
expressed interest in working on independent implementations lost interest and
moved on to other work.

The logjam was successfully broken by three WG actions in the second half of
2015. The first was that the TCP extension functionality of tcpcrypt was split
off into a separate proposal called TCP-ENO (Encryption Negotiation Option).
This extension notably has the ability to negotiate multiple TCP stream
encryption protocols, allowing potentially for runtime negotiation of either
tcpcrypt or tcpinc-use-TLS (or indeed any other future encryption protocol).

The second action was initiated by the chairs. After the Transport AD changed
the WG chairs in July 2015, the new chairs made a call for adoption of both
tcpcrypt and tcpinc-use-TLS. ENO enabled this action by making it credible that
both protocols could be concurrently deployed.

The logjam was finally broken by competing demands for the TLS community,
including for the editor of the tcpinc-use-TLS draft, especially for completion
of TLS 1.3 work in early 2016. This was discussed in the tcpinc WG, and the
resulting rough consensus of the WG was that the appropriate course of action
was to complete work on tcpcrypt and TCP-ENO as soon as possible, making sure
that ENO could eventually support a TLS profile.

Following this decision, rough consensus was achieved fairly rapidly, with only
minor tweaks to the protocol since March 2016. Mailing list traffic has been
very quiet since September 2016, and no tcpinc session was held at IETF 98 in
Chicago.

Expert reviews were conducted by Yoav Nir and Jana Iyengar, with important
additional feedback from mailing list members of CFRG. No fundamental blocking
issues have been revealed through review. The chairs would like an additional
review by the Security Area Directorate.

There is only one current implementation of tcpcrypt, that being the reference
implementation by the Stanford team. At least one other implementation effort
is in progress. The WG chairs believe that a reliable implementation
distributed as part of a major operating system is the best approach to
rekindling interest in this project and for encouraging the development of
additional interoperating implementations.

3. Intellectual Property

Each draft author has stated his/her direct, personal knowledge that any IPR
related to this document has already been disclosed, in conformance with BCPs
78 and 79.

4. Other Points

The original implementation of tcpcrypt squatted on TCP option kind 69, which
caused some controversy and animated discussion on the mailing list. After some
negotiation with Joe Touch, it was decided that tcpcrypt would be willing to
bear the cost of this decision by requesting the same option for assignment by
IANA.

Tcpcrypt requires the addition of an IANA registry with expert review for
"tcpcrypt AEAD parameter", the initial values for which are listed in section
7: this is code point allocation for the AEAD algorithm used for bulk
encryption, symmetric authentication, and integrity protection. Expert
reviewers for this registry should understand the implications of individual
AEAD encryption modes and how they relate to the requirements of both TCP-ENO
and tcpcrypt.

Minimum criteria for a move from Experimental to Proposed Standard status
should include substantive deployment experience spanning multiple
implementations and networks and a BCP document describing deployment
challenges and mitigations, especially with respect to successfully transiting
middle boxes.

Request for posting confirmation emailed to previous authors: Quinn Slack , Dan Boneh , Mike Hamburg , tcpinc-chairs@ietf.org, David Mazieres , Eric Smith , Andrea Bittau , Daniel Giffin , Mark Handley

Request for posting confirmation emailed to previous authors: "David Mazieres" , "Quinn Slack" , "Daniel Giffin" , "Eric Smith" , tcpinc-chairs@ietf.org, "Mike Hamburg" , "Andrea Bittau" , "Dan Boneh" , "Mark Handley"

Request for posting confirmation emailed to previous authors: "David Mazieres" , "Quinn Slack" , "Daniel Giffin" , "Eric Smith" , tcpinc-chairs@ietf.org, "Mike Hamburg" , "Andrea Bittau" , "Dan Boneh" , "Mark Handley"

Request for posting confirmation emailed to previous authors: "Quinn Slack" , "Daniel Giffin" , "Eric Smith" , tcpinc-chairs@ietf.org, "Andrea Bittau" , "Mike Hamburg" , "David Mazieres" , "Dan Boneh" , "Mark Handley"