WebSocket Extension to disable masking
draft-damjanovic-websockets-nomasking-00

HTTP                                                       D. Damjanovic
Internet-Draft                                                 Microsoft
Intended status: Experimental                                19 May 2023
Expires: 20 November 2023

                 WebSocket Extension to disable masking
                draft-damjanovic-websockets-nomasking-00

Abstract

   The WebSocket protocol specifies that all frames sent from the client
   to the server must be masked.  This was introduced as a protection
   against a possible attack on the infrastructure.  With careful
   consideration, the masking could be omitted when intermediaries do
   not have access to the unencrypted traffic.

   This specification introduces a WebSocket extension that disables the
   mandatory masking of frames sent from the client to the server.  The
   extension is allowed only under special circumstances where masking
   is known to be unnecessary.

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 https://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 20 November 2023.

Copyright Notice

   Copyright (c) 2023 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 (https://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

Damjanovic              Expires 20 November 2023                [Page 1]
Internet-Draft   WebSocket Extension to disable masking         May 2023

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   3.  The "no-masking" extension  . . . . . . . . . . . . . . . . .   3
     3.1.  Server behavior considerations  . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   The WebSocket protocol specifies that all frames sent from the client
   to the server must be masked [RFC6455].  This was introduced as a
   protection against a possible attack on the infrastructure described
   in Section 10.3 of [RFC6455].  The attack can be performed on
   intermediaries, such as proxies and it could cause cache poisoning.
   Using end-to-end encryption, the attack can be mitigated without the
   use of masking.  This is because every intermediary will be denied
   access to the unencrypted traffic, which prevents the caching attack.
   The masking has been made mandatory for the connection using TLS to
   protect the infrastructure that is behind TLS terminating proxies.

   This specification introduces a WebSocket extension that disables the
   masking of frames sent from the client to the server.  The support
   for the extension will be advertised by the client (see Section 9 of
   [RFC6455]).  The server may accept the extension only after careful
   consideration discussed in Section Section 3.1.  The extension may
   only be advertised if secure transport is used.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Damjanovic              Expires 20 November 2023                [Page 2]
Internet-Draft   WebSocket Extension to disable masking         May 2023

3.  The "no-masking" extension

   The "no-masking" extension is negotiated using the WebSocket
   extension mechanism described in Section 9 of [RFC6455].  The client
   advertises support for the extension by sending "no-masking" in the
   list of supported extensions sent in the "Sec-WebSocket-Extensions"
   header field.  The server accepts the extension, by sending "no-
   masking" in the "Sec-WebSocket-Extensions" header value.

   The client MUST NOT send the extension if a non-secure connection is
   not used on the connection.  The server MUST reject the upgrade
   request if the "no-masking" extension is advertised on a non-secure
   connection.

   If the "no-masking" extension is negotiated the client and the server
   behavior are:

   *  The client MUST send data to the server without masking.  The
      client sets the field "frame-masked" to 0 on all frames.  As
      defined in [RFC6455], the field "frame-masking-key" will not be
      present.

   *  The server must only accept frames with the field "frame-masked"
      set to 0.  If the server receives a frame with the field "frame-
      masked" set to 1, it MUST close the connection with the status
      code 1002 define in Section 7.4.1 of [RFC6455].

3.1.  Server behavior considerations

   If a WebSocket connection is end-to-end encrypted the server can
   accept the "no-masking" extension.

   In case the connection is not end-to-end encrypted MUST NOT accept
   the "no-masking" extension.

   Intermediaries that terminate TLS connection should remove the
   extension from the "Sec-WebSocket-Extensions" header field.

4.  Security Considerations

   TBA

5.  IANA Considerations

   IANA has registered the following WebSocket extension name in the
   "WebSocket Extension Name Registry" defined in [RFC6455].

   Extension Identifier: no-masking

Damjanovic              Expires 20 November 2023                [Page 3]
Internet-Draft   WebSocket Extension to disable masking         May 2023

   Extension Common Name: Disable the WebSocket client-to-server masking

   Extension Definition: This document.

   Known Incompatible Extensions: None

   The "no-masking" extension name is used in the "Sec-WebSocket-
   Extensions" header in the WebSocket opening handshake to negotiate
   disabling of the client-to-server masking.

6.  Normative References

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, DOI 10.17487/RFC6455, December 2011,
              <https://www.rfc-editor.org/info/rfc6455>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Acknowledgments

Author's Address

   Dragana Damjanovic
   Microsoft
   Email: dragana.damjano@gmail.com

Damjanovic              Expires 20 November 2023                [Page 4]