draft-ietf-tcpinc-tcpcrypt-13.txt   draft-ietf-tcpinc-tcpcrypt-14.txt 
Network Working Group A. Bittau Network Working Group A. Bittau
Internet-Draft Google Internet-Draft Google
Intended status: Experimental D. Giffin Intended status: Experimental D. Giffin
Expires: March 10, 2019 Stanford University Expires: May 8, 2019 Stanford University
M. Handley M. Handley
University College London University College London
D. Mazieres D. Mazieres
Stanford University Stanford University
Q. Slack Q. Slack
Sourcegraph Sourcegraph
E. Smith E. Smith
Kestrel Institute Kestrel Institute
September 6, 2018 November 4, 2018
Cryptographic protection of TCP Streams (tcpcrypt) Cryptographic protection of TCP Streams (tcpcrypt)
draft-ietf-tcpinc-tcpcrypt-13 draft-ietf-tcpinc-tcpcrypt-14
Abstract Abstract
This document specifies tcpcrypt, a TCP encryption protocol designed This document specifies tcpcrypt, a TCP encryption protocol designed
for use in conjunction with the TCP Encryption Negotiation Option for use in conjunction with the TCP Encryption Negotiation Option
(TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating
resegmentation, NATs, and other manipulations of the TCP header. The resegmentation, NATs, and other manipulations of the TCP header. The
protocol is self-contained and specifically tailored to TCP protocol is self-contained and specifically tailored to TCP
implementations, which often reside in kernels or other environments implementations, which often reside in kernels or other environments
in which large external software dependencies can be undesirable. in which large external software dependencies can be undesirable.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 10, 2019. This Internet-Draft will expire on May 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 22, line 17 skipping to change at page 22, line 17
| pubkey_len | pubkey | | pubkey_len | pubkey |
| = L | | | = L | |
+-------+-------+-------+---...---+-------+ +-------+-------+-------+---...---+-------+
Implementations MUST encode these "pubkey" values in "compressed Implementations MUST encode these "pubkey" values in "compressed
format". Implementations MUST validate these "pubkey" values format". Implementations MUST validate these "pubkey" values
according to the algorithm in [IEEE-1363] Section A.16.10. according to the algorithm in [IEEE-1363] Section A.16.10.
Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 use the Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 use the
functions X25519 and X448, respectively, to perform the Diffie-Helman functions X25519 and X448, respectively, to perform the Diffie-Helman
protocol as described in [RFC7748]. When using these ciphers, protocol as described in [RFC7748]. Implementations MUST check
public-key values "Pub_A" and "Pub_B" are transmitted directly with whether the computed Diffie-Hellman shared secret is the all-zero
no length prefix: 32 bytes for Curve25519, and 56 bytes for Curve448. value and abort if so, as described in Section 6 of [RFC7748]. When
using these ciphers, public-key values "Pub_A" and "Pub_B" are
transmitted directly with no length prefix: 32 bytes for Curve25519,
and 56 bytes for Curve448.
Table 2 below specifies the requirement levels of the four TEPs Table 2 below specifies the requirement levels of the four TEPs
specified in this document. In particular, all implementations of specified in this document. In particular, all implementations of
tcpcrypt MUST support TCPCRYPT_ECDHE_Curve25519. However, system tcpcrypt MUST support TCPCRYPT_ECDHE_Curve25519. However, system
administrators MAY configure which TEPs a host will negotiate administrators MAY configure which TEPs a host will negotiate
independent of these implementation requirements. independent of these implementation requirements.
+-------------+---------------------------+ +-------------+---------------------------+
| Requirement | TEP | | Requirement | TEP |
+-------------+---------------------------+ +-------------+---------------------------+
skipping to change at page 25, line 9 skipping to change at page 25, line 9
That is, once an implementation removes these keys from memory, a That is, once an implementation removes these keys from memory, a
compromise of the system will not provide any means to derive the compromise of the system will not provide any means to derive the
session secrets for past connections. All currently-specified key session secrets for past connections. All currently-specified key
agreement schemes involve ECDHE-based key agreement, meaning a new agreement schemes involve ECDHE-based key agreement, meaning a new
key-pair can be efficiently computed for each connection. If key-pair can be efficiently computed for each connection. If
implementations reuse these parameters, they MUST limit the lifetime implementations reuse these parameters, they MUST limit the lifetime
of the private parameters as far as practical in order to minimize of the private parameters as far as practical in order to minimize
the number of past connections that are vulnerable. Of course, the number of past connections that are vulnerable. Of course,
placing private keys in persistent storage introduces severe risks placing private keys in persistent storage introduces severe risks
that they will not be destroyed reliably and in a timely fashion, and that they will not be destroyed reliably and in a timely fashion, and
SHOULD be avoided at all costs. SHOULD be avoided whenever possible.
Attackers cannot force passive openers to move forward in their Attackers cannot force passive openers to move forward in their
session resumption chain without guessing the content of the session resumption chain without guessing the content of the
resumption identifier, which will be difficult without key knowledge. resumption identifier, which will be difficult without key knowledge.
The cipher-suites specified in this document all use HMAC-SHA256 to The cipher-suites specified in this document all use HMAC-SHA256 to
implement the collision-resistant pseudo-random function denoted by implement the collision-resistant pseudo-random function denoted by
"CPRF". A collision-resistant function is one for which, for "CPRF". A collision-resistant function is one for which, for
sufficiently large L, an attacker cannot find two distinct inputs sufficiently large L, an attacker cannot find two distinct inputs
(K_1, CONST_1) and (K_2, CONST_2) such that CPRF(K_1, CONST_1, L) = (K_1, CONST_1) and (K_2, CONST_2) such that CPRF(K_1, CONST_1, L) =
skipping to change at page 26, line 47 skipping to change at page 26, line 47
tradeoff between cryptographic diversity and the ease and security of tradeoff between cryptographic diversity and the ease and security of
actual deployment. actual deployment.
The IETF's appraisal of best current practice on this matter The IETF's appraisal of best current practice on this matter
[RFC7696] says, "Ideally, two independent sets of mandatory-to- [RFC7696] says, "Ideally, two independent sets of mandatory-to-
implement algorithms will be specified, allowing for a primary suite implement algorithms will be specified, allowing for a primary suite
and a secondary suite. This approach ensures that the secondary and a secondary suite. This approach ensures that the secondary
suite is widely deployed if a flaw is found in the primary one." suite is widely deployed if a flaw is found in the primary one."
To meet that ideal, it might appear natural to also mandate ECDHE To meet that ideal, it might appear natural to also mandate ECDHE
using P-256, as this scheme is well-studied, widely implemented, and using P-256. However, implementing the Diffie-Hellman function using
sufficiently different from the Curve25519-based scheme that it is NIST elliptic curves (including those specified for use with
unlikely they will both suffer from a single (non-quantum) tcpcrypt, P-256 and P-521) appears to be very difficult to achieve
cryptanalytic advance. without introducing vulnerability to side-channel attacks
[NIST-fail]. Although well-trusted implementations are available as
However, implementing the Diffie-Hellman function using NIST elliptic part of large cryptographic libraries, these can be difficult to
curves (including those specified for use with tcpcrypt, P-256 and extract for use in operating-system kernels where tcpcrypt is usually
P-521) appears to be very difficult to achieve without introducing best implemented. In contrast, the characteristics of Curve25519
vulnerability to side-channel attacks [NIST-fail]. Although well- together with its recent popularity has led to many safe and
trusted implementations are available as part of large cryptographic efficient implementations, including some that fit naturally into the
libraries, these can be difficult to extract for use in operating- kernel environment.
system kernels where tcpcrypt is usually best implemented. In
contrast, the characteristics of Curve25519 together with its recent
popularity has led to many safe and efficient implementations,
including some that fit naturally into the kernel environment.
[RFC7696] insists that, "The selected algorithms need to be resistant [RFC7696] insists that, "The selected algorithms need to be resistant
to side-channel attacks and also meet the performance, power, and to side-channel attacks and also meet the performance, power, and
code size requirements on a wide variety of platforms." On this code size requirements on a wide variety of platforms." On this
principle, tcpcrypt excludes the NIST curves from the set of principle, tcpcrypt excludes the NIST curves from the set of
mandatory-to-implement key-agreement algorithms. mandatory-to-implement key-agreement algorithms.
Lastly, this document encourages support for key-agreement with Lastly, this document encourages support for key-agreement with
Curve448, categorizing it as RECOMMENDED. Curve448 appears likely to Curve448, categorizing it as RECOMMENDED. Curve448 appears likely to
admit safe and efficient implementations. However, support is not admit safe and efficient implementations. However, support is not
 End of changes. 7 change blocks. 
23 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/