Internet DRAFT - draft-bishop-support-reneg
draft-bishop-support-reneg
HTTPbis Working Group M. Bishop
Internet-Draft Microsoft
Intended status: Informational March 24, 2015
Expires: September 25, 2015
TLS Renegotiation Support Extension to HTTP/2
draft-bishop-support-reneg-00
Abstract
The HTTP/2 spec requires that TLS renegotiation not be employed when
the negotiated application protocol is HTTP/2. This document defines
an extension to HTTP/2 which permits renegotiation to be employed by
peers which mutually consent to do so, while allowing peers to
understand whether renegotiation is permitted before attempting it.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 25, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bishop Expires September 25, 2015 [Page 1]
Internet-Draft Renegotiation Extension to HTTP/2 March 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
2. The TLS_RENEG_PERMITTED Setting . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Normative References . . . . . . . . . . . . . . . . . . 4
5.2. Informative References . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
The HTTP/2 spec [I-D.ietf-httpbis-http2] restricts TLS renegotiation
to before the transmission of the HTTP/2 connection preface. TLS
renegotiation is broadly employed to permit the use of client
certificates as an authentication mechanism. The use of client
certificates is required by law in certain jurisdictions and required
to support upgrading existing applications to HTTP/2 transparently.
Although other mechanisms have been proposed ([I-D.thomson-tls-care],
[I-D.thomson-httpbis-catch], [I-D.nottingham-http-over-version], the
HTTP_1_1_REQUIRED error code in [I-D.ietf-httpbis-http2]), these
uniformly require a separate TCP connection. On this separate TCP
connection, the client would employ either a changed TLS semantic
that must be understood by both sides, or renegotiation underneath an
application protocol which does not prohibit it.
This document defines an extension which permits mutually-consenting
HTTP/2 implementations to perform renegotiation on the existing HTTP
connection when the security properties of renegotiation are
acceptable for their scenarios and the TLS version in use supports
it.
1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
All numeric values are in network byte order. Values are unsigned
unless otherwise indicated. Literal values are provided in decimal
or hexadecimal as appropriate. Hexadecimal literals are prefixed
with "0x" to distinguish them from decimal literals.
Bishop Expires September 25, 2015 [Page 2]
Internet-Draft Renegotiation Extension to HTTP/2 March 2015
2. The TLS_RENEG_PERMITTED Setting
This document defines a new setting value in HTTP/2,
TLS_RENEG_PERMITTED, with code TBD and an initial value of 0x00.
The thirty-two bits of the setting value are interpreted as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (30) |S|C|
+---------------------------------------------------------------+
Setting Value Definition
The effective state for an HTTP/2 connection is the bitwise AND of
the values sent by each peer.
Either peer is permitted to initiate TLS renegotiation if this
behavior is mutually agreeable. The recipient MUST treat a TLS
renegotiation as a connection error of type PROTOCOL_ERROR if support
for renegotiation has not previously been agreed upon.
The defined bits are:
C (Bit 0) If set, client-initiated renegotiation is allowed.
S (Bit 1) If set, server-initiated renegotiation is allowed.
All other bits are undefined, and MUST be zero when sent and ignored
upon receipt.
3. Security Considerations
In [RFC5746], an attack is described in which renegotiation can be
exploited by an intermediary to inject attacker-controlled content
before the content contained in the TLS connection the client
believes it has established with the server. The TLS extension
described in that document cryptographically ties the sessions and
prevents the attack described.
HTTP/2 includes attributes which would make a similar attack more
challenging than in HTTP/1.1. Thus, renegotiation in HTTP/2 may be
preferable to renegotiation under an HTTP/1.1 connection.
Implementers will need to consider the security context of the
current connection when deciding when to offer this extension.
Bishop Expires September 25, 2015 [Page 3]
Internet-Draft Renegotiation Extension to HTTP/2 March 2015
4. IANA Considerations
A new setting is defined for HTTP/2 in the "HTTP/2 Settings"
registry.
o Name: TLS_RENEG_PERMITTED
o Code: TBD
o Initial value: 0x00
o Specification: This document
5. References
5.1. Normative References
[I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol version 2", draft-ietf-httpbis-http2-17 (work in
progress), February 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informative References
[I-D.nottingham-http-over-version]
Nottingham, M., "The Over-Version HTTP Response Header
Field", draft-nottingham-http-over-version-00 (work in
progress), June 2014.
[I-D.thomson-httpbis-catch]
Thomson, M., "Client Authentication over TLS Connection
Header", draft-thomson-httpbis-catch-00 (work in
progress), March 2014.
[I-D.thomson-tls-care]
Thomson, M., "Client Authentication Request Extension for
(D)TLS", draft-thomson-tls-care-00 (work in progress),
March 2014.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, February 2010.
Bishop Expires September 25, 2015 [Page 4]
Internet-Draft Renegotiation Extension to HTTP/2 March 2015
Author's Address
Mike Bishop
Microsoft
EMail: michbish@microsoft.com
Bishop Expires September 25, 2015 [Page 5]
