Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
RFC 7627
| Document | Type |
RFC
- Proposed Standard
(September 2015)
Updates RFC 5246
|
|
|---|---|---|---|
| Authors | Karthikeyan Bhargavan , Antoine Delignat-Lavaud , Alfredo Pironti , Adam Langley , Marsh Ray | ||
| Last updated | 2015-10-14 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Stephen Farrell | |
| Send notices to | (None) |
RFC 7627
#x27;s
IP address. This is always the case when using a SSM {S,G} channel.
5.1.1. Usage of UDP for source port entropy and the IPv6 Flow Label
Some applications use the UDP datagram header as a source of entropy
for network devices that implement ECMP [RFC6438]. A UDP tunnel
application targeting this usage, encapsulates an inner packet using
UDP, where the UDP source port value forms a part of the entropy that
can be used to balance forwarding of network traffic by the devices
that use ECMP. A sending tunnel endpoint selects a source port value
in the UDP datagram header that is computed from the inner flow
information (e.g., the encapsulated packet headers). To provide
sufficient entropy the sending tunnel endpoint maps the encapsulated
traffic to one of a range of UDP source values. The value SHOULD be
within the ephemeral port range, i.e., 49152 to 65535, where the high
order two bits of the port are set to one. The available source port
entropy of 14 bits (using the ephemeral port range) plus the outer IP
addresses seems sufficient for entropy for most ECMP applications
[I-D.ietf-rtgwg-dt-encap].
To avoid reordering within an IP flow, the same UDP source port value
SHOULD be used for all packets assigned to an encapsulated flow
(e.g., using a hash of the relevant headers). The entropy mapping
for a flow MAY change over the lifetime of the encapsulated flow
[I-D.ietf-rtgwg-dt-encap]. For instance, this could be changed as a
Denial of Service (DOS) mitigation, or as a means to effect routing
through the ECMP network. However, the source port selected for a
flow SHOULD NOT change more than once in every thirty seconds (e.g.,
as in [I-D.ietf-tsvwg-gre-in-udp-encap]).
The use of the source port field for entropy has several side-effects
that need to be considered, including:
o It can increase the probability of misdelivery of corrupted
packets, which increases the need for checksum computation or an
equivalent mechanism to protect other UDP applications from
misdelivery errors Section 3.4.
o It is expected to reduce the probability of successful middlebox
traversal Section 3.5. This use of the source port field will
often not be suitable for applications targeting deployment in the
general Internet.
Eggert, et al. Expires October 6, 2016 [Page 32]
Internet-Draft UDP Usage Guidelines April 2016
o It can prevent the field being usable to protect from off-path
attacks (described inSection 5.1). Designers therefore need to
consider other mechanisms to provide equivalent protection (e.g.,
to restrict use to a controlled environment [RFC7510]
Section 3.6).
The UDP source port number field has also been leveraged to produce
entropy with IPv6. However, in the case of IPv6, the "flow label"
[RFC6437] may also alternatively be used as entropy for load
balancing [RFC6438]. This use of the flow label for load balancing
is consistent with the definition of the field, although further
clarity was needed to ensure the field can be consistently used for
this purpose. Therefore, an updated IPv6 flow label [RFC6437] and
ECMP routing [RFC6438] usage was specified.
To ensure future opportunities to use the flow label, UDP
applications SHOULD set the flow label field, even when an entropy
value is also set in the source port field (e.g., An IPv6 tunnel
endpoint could copy the source port flow entropy value to the IPv6
flow label field [I-D.ietf-tsvwg-gre-in-udp-encap]). Router vendors
are encouraged to start using the IPv6 flow label as a part of the
flow hash, providing support for IP-level ECMP without requiring use
of UDP. The end-to-end use of flow labels for load balancing is a
long-term solution. Even if the usage of the flow label has been
clarified, there will be a transition time before a significant
proportion of endpoints start to assign a good quality flow label to
the flows that they originate. The use of load balancing using the
transport header fields will likely continue until widespread
deployment is finally achieved.
5.1.2. Applications using Multiple UDP Ports
A single application may exchange several types of data. In some
cases, this may require multiple UDP flows (e.g., multiple sets of
flows, identified by different five-tuples). [RFC6335] recommends
application developers not to apply to IANA to be assigned multiple
well-known ports (user or system). This does not discuss the
implications of using multiple flows with the same well-known port or
pairs of dynamic ports (e.g., identified by a service name or
signaling protocol).
Use of multiple flows can affect the network in several ways:
o Starting a series of successive connections can increase the
number of state bindings in middleboxes (e.g., NAPT or Firewall)
along the network path. UDP-based middlebox traversal usually
relies on timeouts to remove old state, since middleboxes are
Eggert, et al. Expires October 6, 2016 [Page 33]
Internet-Draft UDP Usage Guidelines April 2016
unaware when a particular flow ceases to be used by an
application.
o Using several flows at the same time may result in seeing
different network characteristics for each flow. It cannot be
assumed both follow the same path (e.g., when ECMP is used,
traffic is intentionally hashed onto different parallel paths
based on the port numbers).
o Using several flows can also increase the occupancy of a binding
or lookup table in a middlebox (e.g., NAPT or Firewall), which may
cause the device to change the way it manages the flow state.
o Further, using excessive numbers of flows can degrade the ability
of a unicast congestion control to react to congestion events,
unless the congestion state is shared between all flows in a
session. A receiver-driven multicast congestion control requires
the sending application to distribute its data over a set of IP
multicast groups, each receiver is therefore expected to receive
data from a modest number of simultaneously active UDP ports.
Therefore, applications MUST NOT assume consistent behavior of
middleboxes when multiple UDP flows are used; many devices respond
differently as the number of used ports increases. Using multiple
flows with different QoS requirements requires applications to verify
that the expected performance is achieved using each individual flow
(five-tuple), see Section 3.1.7.
5.2. ICMP Guidelines
Applications can utilize information about ICMP error messages that
the UDP layer passes up for a variety of purposes [RFC1122].
Applications SHOULD appropriately validate the payload of ICMP
messages to ensure these are received in response to transmitted
traffic (i.e., a reported error condition that corresponds to a UDP
datagram actually sent by the application). This requires context,
such as local state about communication instances to each
destination, that although readily available in connection-oriented
transport protocols is not always maintained by UDP-based
applications. Note that not all platforms have the necessary APIs to
support this validation, and some platforms already perform this
validation internally before passing ICMP information to the
application.
Any application response to ICMP error messages SHOULD be robust to
temporary routing failures (sometimes called "soft errors"), e.g.,
transient ICMP "unreachable" messages ought to not normally cause a
communication abort.
Eggert, et al. Expires October 6, 2016 [Page 34]
Internet-Draft UDP Usage Guidelines April 2016
As mentioned above, ICMP messages are being increasingly filtered by
middleboxes. A UDP application therefore SHOULD NOT rely on their
delivery for correct and safe operation.
6. Security Considerations
UDP does not provide communications security. Applications that need
to protect their communications against eavesdropping, tampering, or
message forgery SHOULD employ end-to-end security services provided
by other IETF protocols.
UDP applications SHOULD provide protection from off-path data
injection attacks using a randomized source port or equivalent
technique (see Section 5.1).
Applications that respond to short requests with potentially large
responses are vulnerable to amplification attacks, and SHOULD
authenticate the sender before responding. The source IP address of
a request is not a useful authenticator, because it can easily be
spoofed.
One option for securing UDP communications is with IPsec [RFC4301],
which can provide authentication for flows of IP packets through the
Authentication Header (AH) [RFC4302] and encryption and/or
authentication through the Encapsulating Security Payload (ESP)
[RFC4303]. Applications use the Internet Key Exchange (IKE)
[RFC7296] to configure IPsec for their sessions. Depending on how
IPsec is configured for a flow, it can authenticate or encrypt the
UDP headers as well as UDP payloads. If an application only requires
authentication, ESP with no encryption but with authentication is
often a better option than AH, because ESP can operate across
middleboxes. An application that uses IPsec requires the support of
an operating system that implements the IPsec protocol suite.
Although it is possible to use IPsec to secure UDP communications,
not all operating systems support IPsec or allow applications to
easily configure it for their flows. A second option for securing
UDP communications is through Datagram Transport Layer Security
(DTLS) [RFC6347]. DTLS provides communication privacy by encrypting
UDP payloads. It does not protect the UDP headers. Applications can
implement DTLS without relying on support from the operating system.
Many other options for authenticating or encrypting UDP payloads
exist. For example, the GSS-API security framework [RFC2743] or
Cryptographic Message Syntax (CMS) [RFC5652] could be used to protect
UDP payloads. There exist a number of security options for RTP
[RFC3550] over UDP, especially to accomplish key-management, see
[RFC7201]. These options covers many usages, including point-to-
Eggert, et al. Expires October 6, 2016 [Page 35]
Internet-Draft UDP Usage Guidelines April 2016
point, centralized group communication as well as multicast. In some
applications, a better solution is to protect larger stand-alone
objects, such as files or messages, instead of individual UDP
payloads. In these situations, CMS [RFC5652], S/MIME [RFC5751] or
OpenPGP [RFC4880] could be used. In addition, there are many non-
IETF protocols in this area.
Like congestion control mechanisms, security mechanisms are difficult
to design and implement correctly. It is hence RECOMMENDED that
applications employ well-known standard security mechanisms such as
DTLS or IPsec, rather than inventing their own.
The Generalized TTL Security Mechanism (GTSM) [RFC5082] may be used
with UDP applications when the intended endpoint is on the same link
as the sender. This lightweight mechanism allows a receiver to
filter unwanted packets.
In terms of congestion control, [RFC2309] and [RFC2914] discuss the
dangers of congestion-unresponsive flows to the Internet.
[I-D.ietf-tsvwg-circuit-breaker] describes methods that can be used
to set a performance envelope that can assist in preventing
congestion collapse in the absence of congestion control or when the
congestion control fails to react to congestion events. This
document provides guidelines to designers of UDP-based applications
to congestion-control their transmissions, and does not raise any
additional security concerns.
Some network operators have experienced surges of UDP attack traffic
that are multiple orders of magnitude above the baseline traffic rate
for UDP. This can motivate operators to limit the data rate or
packet rate of UDP traffic. This may in turn limit the throughput
that an application can achieve using UDP and could also result in
higher packet loss for UDP traffic that would not be experienced if
other transport protocols had been used.
A UDP application with a long-lived association between the sender
and receiver, ought to be designed so that the sender periodically
checks that the receiver still wants ("consents") to receive traffic
and need to be designed to stop if there is no explicit confirmation
of this [RFC7675]. Applications that require communications in two
directions to implement protocol functions (such as reliability or
congestion control) will need to independently check both directions
of communication, and may have to exchange keep-alive packets to
traverse middleboxes (see Section 3.5).
Eggert, et al. Expires October 6, 2016 [Page 36]
Internet-Draft UDP Usage Guidelines April 2016
7. Summary
This section summarizes the key guidelines made in Sections 3 - 6 in
a tabular format (Table 1) for easy referencing.
+---------------------------------------------------------+---------+
| Recommendation | Section |
+---------------------------------------------------------+---------+
| MUST tolerate a wide range of Internet path conditions | 3 |
| SHOULD use a full-featured transport (TCP, SCTP, DCCP) | |
| | |
| SHOULD control rate of transmission | 3.1 |
| SHOULD perform congestion control over all traffic | |
| | |
| for bulk transfers, | 3.1.1 |
| SHOULD consider implementing TFRC | |
| else, SHOULD in other ways use bandwidth similar to TCP | |
| | |
| for non-bulk transfers, | 3.1.2 |
| SHOULD measure RTT and transmit max. 1 datagram/RTT | |
| else, SHOULD send at most 1 datagram every 3 seconds | |
| SHOULD back-off retransmission timers following loss | |
| | |
| SHOULD provide mechanisms to regulate the bursts of | 3.1.4 |
| transmission | |
| | |
| MAY implement ECN; a specific set of application | 3.1.5 |
| mechanisms are REQUIRED if ECN is used. | |
| | |
| for DiffServ, SHOULD NOT rely on implementation of PHBs | 3.1.6 |
| | |
| for QoS-enabled paths, MAY choose not to use CC | 3.1.7 |
| | |
| SHOULD NOT rely solely on QoS for their capacity | 3.1.8 |
| non-CC controlled flows SHOULD implement a transport | |
| circuit breaker | |
| MAY implement a circuit breaker for other applications | |
| | |
| for tunnels carrying IP Traffic, | 3.1.9 |
| SHOULD NOT perform congestion control | |
| MUST correctly process the IP ECN field | |
| | |
| for non-IP tunnels or rate not determined by traffic, | |
| SHOULD perform CC or use circuit breaker | 3.1.9 |
| SHOULD restrict types of traffic transported by the | |
| tunnel | |
| | |
| SHOULD NOT send datagrams that exceed the PMTU, i.e., | 3.2 |
Eggert, et al. Expires October 6, 2016 [Page 37]
Internet-Draft UDP Usage Guidelines April 2016
| SHOULD discover PMTU or send datagrams < minimum PMTU; | |
| Specific application mechanisms are REQUIRED if PLPMTUD | |
| is used. | |
| | |
| SHOULD handle datagram loss, duplication, reordering | 3.3 |
| SHOULD be robust to delivery delays up to 2 minutes | |
| | |
| SHOULD enable IPv4 UDP checksum | 3.4 |
| SHOULD enable IPv6 UDP checksum; Specific application | 3.4.1 |
| mechanisms are REQUIRED if a zero IPv6 UDP checksum is | |
| used. | |
| | |
| SHOULD provide protection from off-path attacks | 5.1 |
| else, MAY use UDP-Lite with suitable checksum coverage | 3.4.2 |
| | |
| SHOULD NOT always send middlebox keep-alives | 3.5 |
| MAY use keep-alives when needed (min. interval 15 sec) | |
| | |
| Applications specifyied for use in limited use (or | 3.6 |
| controlled environments) SHOULD identify equivalent | |
| mechanisms and describe their use-case. | |
| | |
| Bulk multicast apps SHOULD implement congestion control | 4.1.1 |
| | |
| Low volume multicast apps SHOULD implement congestion | 4.1.2 |
| control | |
| | |
| Multicast apps SHOULD use a safe PMTU | 4.2 |
| | |
| SHOULD avoid using multiple ports | 5.1 |
| MUST check received IP source address | |
| | |
| SHOULD use a randomized source port or equivalent | 5.2 |
| technique, and, for client/server applications, SHOULD | |
| send responses from source address matching request | |
| | |
| SHOULD validate payload in ICMP messages | 5.2 |
| | |
| SHOULD use standard IETF security protocols when needed | 6 |
+---------------------------------------------------------+---------+
Table 1: Summary of recommendations
8. IANA Considerations
Note to RFC-Editor: please remove this entire section prior to
publication.
Eggert, et al. Expires October 6, 2016 [Page 38]
Internet-Draft UDP Usage Guidelines April 2016
This document raises no IANA considerations.
9. Acknowledgments
The middlebox traversal guidelines in Section 3.5 incorporate ideas
from Section 5 of [I-D.ford-behave-app] by Bryan Ford, Pyda
Srisuresh, and Dan Kegel. G. Fairhurst received funding from the
European Union's Horizon 2020 research and innovation program
2014-2018 under grant agreement No. 644334 (NEAT). Lars Eggert has
received funding from the European Union's Horizon 2020 research and
innovation program 2014-2018 under grant agreement No. 644866
("SSICLOPS"). This document reflects only the authors' views and the
European Commission is not responsible for any use that may be made
of the information it contains.
10. References
10.1. Normative References
[I-D.ietf-tsvwg-circuit-breaker]
Fairhurst, G., "Network Transport Circuit Breakers",
draft-ietf-tsvwg-circuit-breaker-14 (work in progress),
March 2016.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>.
Eggert, et al. Expires October 6, 2016 [Page 39]
Internet-Draft UDP Usage Guidelines April 2016
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<http://www.rfc-editor.org/info/rfc2914>.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
and G. Fairhurst, Ed., "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
2004, <http://www.rfc-editor.org/info/rfc3828>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008,
<http://www.rfc-editor.org/info/rfc5348>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
DOI 10.17487/RFC5405, November 2008,
<http://www.rfc-editor.org/info/rfc5405>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>.
Eggert, et al. Expires October 6, 2016 [Page 40]
Internet-Draft UDP Usage Guidelines April 2016
10.2. Informative References
[ALLMAN] Allman, M. and E. Blanton, "Notes on burst mitigation for
transport protocols", March 2005.
[FABER] Faber, T., Touch, J., and W. Yue, "The TIME-WAIT State in
TCP and Its Effect on Busy Servers", Proc. IEEE Infocom,
March 1999.
[I-D.ford-behave-app]
Ford, B., "Application Design Guidelines for Traversal
through Network Address Translators", draft-ford-behave-
app-05 (work in progress), March 2007.
[I-D.ietf-aqm-ecn-benefits]
Fairhurst, G. and M. Welzl, "The Benefits of using
Explicit Congestion Notification (ECN)", draft-ietf-aqm-
ecn-benefits-08 (work in progress), November 2015.
[I-D.ietf-avtcore-rtp-circuit-breakers]
Perkins, C. and V. Varun, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-14 (work in progress), March
2016.
[I-D.ietf-intarea-tunnels]
Touch, J. and W. Townsley, "IP Tunnels in the Internet
Architecture", draft-ietf-intarea-tunnels-02 (work in
progress), January 2016.
[I-D.ietf-rtgwg-dt-encap]
Nordmark, E., Tian, A., Gross, J., Hudson, J., Kreeger,
L., Garg, P., Thaler, P., and T. Herbert, "Encapsulation
Considerations", draft-ietf-rtgwg-dt-encap-01 (work in
progress), March 2016.
[I-D.ietf-tsvwg-gre-in-udp-encap]
Yong, L., Crabbe, E., Xu, X., and T. Herbert, "GRE-in-UDP
Encapsulation", draft-ietf-tsvwg-gre-in-udp-encap-11 (work
in progress), March 2016.
[POSIX] IEEE Std. 1003.1-2001, , "Standard for Information
Technology - Portable Operating System Interface (POSIX)",
Open Group Technical Standard: Base Specifications Issue
6, ISO/IEC 9945:2002, December 2001.
Eggert, et al. Expires October 6, 2016 [Page 41]
Internet-Draft UDP Usage Guidelines April 2016
[RFC0896] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC 896, DOI 10.17487/RFC0896, January 1984,
<http://www.rfc-editor.org/info/rfc896>.
[RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5,
RFC 919, DOI 10.17487/RFC0919, October 1984,
<http://www.rfc-editor.org/info/rfc919>.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, DOI 10.17487/RFC1112, August 1989,
<http://www.rfc-editor.org/info/rfc1112>.
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
Miller, "Common DNS Implementation Errors and Suggested
Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993,
<http://www.rfc-editor.org/info/rfc1536>.
[RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC 1546, DOI 10.17487/RFC1546,
November 1993, <http://www.rfc-editor.org/info/rfc1546>.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,
<http://www.rfc-editor.org/info/rfc2309>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, DOI 10.17487/RFC2675, August 1999,
<http://www.rfc-editor.org/info/rfc2675>.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743,
DOI 10.17487/RFC2743, January 2000,
<http://www.rfc-editor.org/info/rfc2743>.
[RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R.,
Vicisano, L., and M. Luby, "The Reliable Multicast Design
Space for Bulk Data Transfer", RFC 2887,
DOI 10.17487/RFC2887, August 2000,
<http://www.rfc-editor.org/info/rfc2887>.
Eggert, et al. Expires October 6, 2016 [Page 42]
Internet-Draft UDP Usage Guidelines April 2016
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S., and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, DOI 10.17487/RFC3048, January 2001,
<http://www.rfc-editor.org/info/rfc3048>.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, DOI 10.17487/RFC3124, June 2001,
<http://www.rfc-editor.org/info/rfc3124>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
A. Rayhan, "Middlebox communication architecture and
framework", RFC 3303, DOI 10.17487/RFC3303, August 2002,
<http://www.rfc-editor.org/info/rfc3303>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, February 2003,
<http://www.rfc-editor.org/info/rfc3493>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>.
Eggert, et al. Expires October 6, 2016 [Page 43]
Internet-Draft UDP Usage Guidelines April 2016
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738,
DOI 10.17487/RFC3738, April 2004,
<http://www.rfc-editor.org/info/rfc3738>.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758,
DOI 10.17487/RFC3758, May 2004,
<http://www.rfc-editor.org/info/rfc3758>.
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, DOI 10.17487/RFC3819, July 2004,
<http://www.rfc-editor.org/info/rfc3819>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<http://www.rfc-editor.org/info/rfc4340>.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, DOI 10.17487/RFC4341, March
2006, <http://www.rfc-editor.org/info/rfc4341>.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
DOI 10.17487/RFC4342, March 2006,
<http://www.rfc-editor.org/info/rfc4342>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<http://www.rfc-editor.org/info/rfc4607>.
Eggert, et al. Expires October 6, 2016 [Page 44]
Internet-Draft UDP Usage Guidelines April 2016
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast
Congestion Control (TFMCC): Protocol Specification",
RFC 4654, DOI 10.17487/RFC4654, August 2006,
<http://www.rfc-editor.org/info/rfc4654>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007,
<http://www.rfc-editor.org/info/rfc4880>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963,
DOI 10.17487/RFC4963, July 2007,
<http://www.rfc-editor.org/info/rfc4963>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<http://www.rfc-editor.org/info/rfc4987>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<http://www.rfc-editor.org/info/rfc5082>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate
Control for Small Packets (TFRC-SP)", RFC 5622,
DOI 10.17487/RFC5622, August 2009,
<http://www.rfc-editor.org/info/rfc5622>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, DOI 10.17487/RFC5740, November 2009,
<http://www.rfc-editor.org/info/rfc5740>.
Eggert, et al. Expires October 6, 2016 [Page 45]
Internet-Draft UDP Usage Guidelines April 2016
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous
Layered Coding (ALC) Protocol Instantiation", RFC 5775,
DOI 10.17487/RFC5775, April 2010,
<http://www.rfc-editor.org/info/rfc5775>.
[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", RFC 5971, DOI 10.17487/RFC5971,
October 2010, <http://www.rfc-editor.org/info/rfc5971>.
[RFC5973] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies,
"NAT/Firewall NSIS Signaling Layer Protocol (NSLP)",
RFC 5973, DOI 10.17487/RFC5973, October 2010,
<http://www.rfc-editor.org/info/rfc5973>.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
DOI 10.17487/RFC6056, January 2011,
<http://www.rfc-editor.org/info/rfc6056>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<http://www.rfc-editor.org/info/rfc6335>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6396] Blunk, L., Karir, M., and C. Labovitz, "Multi-Threaded
Routing Toolkit (MRT) Routing Information Export Format",
RFC 6396, DOI 10.17487/RFC6396, October 2011,
<http://www.rfc-editor.org/info/rfc6396>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<http://www.rfc-editor.org/info/rfc6437>.
Eggert, et al. Expires October 6, 2016 [Page 46]
Internet-Draft UDP Usage Guidelines April 2016
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<http://www.rfc-editor.org/info/rfc6438>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <http://www.rfc-editor.org/info/rfc6679>.
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen,
"FLUTE - File Delivery over Unidirectional Transport",
RFC 6726, DOI 10.17487/RFC6726, November 2012,
<http://www.rfc-editor.org/info/rfc6726>.
[RFC6807] Farinacci, D., Shepherd, G., Venaas, S., and Y. Cai,
"Population Count Extensions to Protocol Independent
Multicast (PIM)", RFC 6807, DOI 10.17487/RFC6807, December
2012, <http://www.rfc-editor.org/info/rfc6807>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013,
<http://www.rfc-editor.org/info/rfc6887>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
UDP Checksums for Tunneled Packets", RFC 6935,
DOI 10.17487/RFC6935, April 2013,
<http://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013,
<http://www.rfc-editor.org/info/rfc6936>.
[RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black,
"Internet Small Computer System Interface (iSCSI) Protocol
(Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April
2014, <http://www.rfc-editor.org/info/rfc7143>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>.
Eggert, et al. Expires October 6, 2016 [Page 47]Bhargavan, et al. Standards Track [Page 10]
RFC 7627 TLS Session Hash Extension September 2015
properties relying on the uniqueness of the master secret are now
expected to hold. In particular, if a TLS session is protected by
the extended master secret extension, it is safe to resume it, to use
its channel bindings, and to allow for certificate changes across
renegotiation, meaning that all certificates are controlled by the
same peer. A symbolic cryptographic protocol analysis justifying the
extended master secret extension appears in [VERIFIED-BINDINGS].
6.2. Cryptographic Properties of the Hash Function
The session hashes of two different sessions need to be distinct;
hence, the "Hash" function used to compute the "session_hash" needs
to be collision resistant. As such, hash functions such as MD5 or
SHA1 are NOT RECOMMENDED.
We observe that the "Hash" function used in the Finished message
computation already needs to be collision resistant for the
renegotiation indication extension [RFC5746] to work, because a
meaningful collision on the handshake messages (and hence on the
"verify_data") may re-enable the renegotiation attack [Ray09].
The hash function used to compute the session hash depends on the TLS
protocol version. All current ciphersuites defined for TLS 1.2 use
SHA256 or better, and so does the session hash. For earlier versions
of the protocol, only MD5 and SHA1 can be assumed to be supported,
and this document does not require legacy implementations to add
support for new hash functions. In these versions, the session hash
uses the concatenation of MD5 and SHA1, as in the Finished message.
6.3. Handshake Messages Included in the Session Hash
The "session_hash" is intended to encompass all relevant session
information, including ciphersuite negotiation, key exchange
messages, and client and server identities. The hash is needed to
compute the extended master secret and hence must be available before
the Finished messages.
This document sets the "session_hash" to cover all handshake messages
up to and including the ClientKeyExchange. For existing TLS
ciphersuites, these messages include all the significant contents of
the new session -- CertificateVerify does not change the session
content. At the same time, this allows the extended master secret to
be computed immediately after the pre-master secret, so that
implementations can shred the temporary pre-master secret from memory
as early as possible.
Bhargavan, et al. Standards Track [Page 11]
RFC 7627 TLS Session Hash Extension September 2015
It is possible that new ciphersuites or TLS extensions may include
additional messages between ClientKeyExchange and Finished that add
important session context. In such cases, some of the security
guarantees of this specification may no longer apply, and new man-in-
the-middle attacks may be possible. For example, if the client and
server support the session ticket extension [RFC5077], the session
hash does not cover the new session ticket sent by the server.
Hence, a man-in-the-middle may be able to cause a client to store a
session ticket that was not meant for the current session. Attacks
based on this vector are not yet known, but applications that store
additional information in session tickets beyond those covered in the
session hash require careful analysis.
6.4. No SSL 3.0 Support
The Secure Sockets Layer (SSL) protocol version 3.0 [RFC6101] is a
predecessor of the TLS protocol, and it is equally vulnerable to
triple handshake attacks, alongside other vulnerabilities stemming
from its use of obsolete cryptographic constructions that are now
considered weak. SSL 3.0 has been deprecated [RFC7568].
The countermeasure described in this document relies on a TLS
extension and hence cannot be used with SSL 3.0. Clients and servers
implementing this document SHOULD refuse SSL 3.0 handshakes. If they
choose to support SSL 3.0, the resulting sessions MUST use the legacy
master secret computation, and the interoperability considerations of
Section 5.4 apply.
7. IANA Considerations
IANA has added the extension code point 23 (0x0017), which has been
used by prototype implementations, for the "extended_master_secret"
extension to the "ExtensionType Values" registry specified in the TLS
specification [RFC5246].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
Bhargavan, et al. Standards Track [Page 12]
RFC 7627 TLS Session Hash Extension September 2015
8.2. Informative References
[COMPOUND-AUTH]
Asokan, N., Valtteri, N., and K. Nyberg, "Man-in-the-
Middle in Tunnelled Authentication Protocols", Security
Protocols, LNCS, Volume 3364, DOI 10.1007/11542322_6,
2005.
[Ray09] Ray, M., "Authentication Gap in TLS Renegotiation", 2009.
[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251,
January 2006, <http://www.rfc-editor.org/info/rfc4251>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption
without Server-Side State", RFC 5077,
DOI 10.17487/RFC5077, January 2008,
<http://www.rfc-editor.org/info/rfc5077>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <http://www.rfc-editor.org/info/rfc5705>.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, DOI 10.17487/RFC5746, February
2010, <http://www.rfc-editor.org/info/rfc5746>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<http://www.rfc-editor.org/info/rfc5929>.
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
DOI 10.17487/RFC6101, August 2011,
<http://www.rfc-editor.org/info/rfc6101>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <http://www.rfc-editor.org/info/rfc7457>.
Bhargavan, et al. Standards Track [Page 13]
RFC 7627 TLS Session Hash Extension September 2015
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
DOI 10.17487/RFC7568, June 2015,
<http://www.rfc-editor.org/info/rfc7568>.
[SP800-108] Chen, L., "Recommendation for Key Derivation Using
Pseudorandom Functions (Revised)", NIST Special
Publication 800-108, 2009.
[TRIPLE-HS] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
A., and P-Y. Strub, "Triple Handshakes and Cookie
Cutters: Breaking and Fixing Authentication over TLS",
IEEE Symposium on Security and Privacy,
DOI 10.1109/SP.2014.14, 2014.
[VERIFIED-BINDINGS]
Bhargavan, K., Delignat-Lavaud, A., and A. Pironti,
"Verified Contributive Channel Bindings for Compound
Authentication", Network and Distributed System Security
Symposium (NDSS), 2015.
Acknowledgments
Triple handshake attacks were originally discovered by Antoine
Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti. They
were further developed by the miTLS team: Cedric Fournet, Pierre-Yves
Strub, Markulf Kohlweiss, and Santiago Zanella-Beguelin. Many of the
ideas in this document emerged from discussions with Martin Abadi,
Ben Laurie, Nikos Mavrogiannopoulos, Manuel Pegourie-Gonnard, Eric
Rescorla, Martin Rex, and Brian Smith.
Bhargavan, et al. Standards Track [Page 14]
RFC 7627 TLS Session Hash Extension September 2015
Authors' Addresses
Karthikeyan Bhargavan (editor)
Inria Paris-Rocquencourt
23, Avenue d'Italie
Paris 75214 CEDEX 13
France
Email: karthikeyan.bhargavan@inria.fr
Antoine Delignat-Lavaud
Inria Paris-Rocquencourt
23, Avenue d'Italie
Paris 75214 CEDEX 13
France
Email: antoine.delignat-lavaud@inria.fr
Alfredo Pironti
Inria Paris-Rocquencourt
23, Avenue d'Italie
Paris 75214 CEDEX 13
France
Email: alfredo.pironti@inria.fr
Adam Langley
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States
Email: agl@google.com
Marsh Ray
Microsoft Corp.
1 Microsoft Way
Redmond, WA 98052
United States
Email: maray@microsoft.com
Bhargavan, et al. Standards Track [Page 15]