Internet Engineering Task Force                                  Ranalvi
Internet-Draft                                           24 January 2025
Intended status: Informational                                          
Expires: 28 July 2025


    Introducing `s://` as a Secure URL Scheme to replace `https://`
                     draft-aranalvi-s-url-scheme-00

Abstract

   This document proposes the introduction of `s://` as a universal
   shorthand for secure URLs, replacing the explicit use of `https://`.
   The proposed scheme simplifies URL syntax, assumes secure connections
   by default, and aligns with the modern web's security-first approach.
   The adoption of `s://` is expected to enhance user experience,
   improve efficiency, and reinforce secure practices across the
   internet.

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 28 July 2025.

Copyright Notice

   Copyright (c) 2025 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Ranalvi                   Expires 28 July 2025                  [Page 1]

Internet-Draft        `s://` as a Secure URL Scheme         January 2025


   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
   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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Proposed Solution . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Challenges & Mitigations  . . . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   URLs are a foundational element of the internet, allowing users to
   locate resources using protocols such as HTTP, HTTPS, and FTP.  In
   recent years, HTTPS adoption has grown significantly, driven by
   security concerns and performance improvements offered by TLS
   [RFC8446].  Despite this shift, URLs still explicitly distinguish
   between `http://` (insecure) and `https://` (secure).  This explicit
   declaration is redundant in a web environment where security should
   be the default [RFC9110].  This document proposes the introduction of
   `s://` as a shorthand for secure URLs, simplifying the syntax and
   reinforcing the norm of secure connections.

1.1.  Requirements Language

   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.








Ranalvi                   Expires 28 July 2025                  [Page 2]

Internet-Draft        `s://` as a Secure URL Scheme         January 2025


2.  Proposed Solution

   The `s://` scheme is defined as a shorthand for `https://`. When a
   client encounters `s://`, it MUST interpret and process it as a
   secure HTTPS connection [RFC3986].  Existing URLs using `https://`
   remain fully functional, ensuring no disruption to current systems.
   The `http://` scheme may continue to function during a transition
   period but is expected to be deprecated in the future.

   The `s://` scheme SHALL remain compatible with HTTP/1.1 [RFC9112] and
   HTTP/3 semantics [RFC9114].

3.  Motivation

   *  Security as the Default: The internet has evolved to prioritize
      secure connections, with HTTPS adoption exceeding 90% of global
      web traffic.  The explicit declaration of `https://` is redundant
      and assumes that insecure `http://` is still a viable option,
      which it should no longer be.

   *  Improved Usability: Users often ignore or misunderstand the
      difference between `http://` and `https://`. A streamlined `s://`
      scheme eliminates confusion and simplifies the user experience.

   *  Efficiency Gains: Reducing the length of URLs saves bandwidth,
      storage, and processing power.  For systems handling billions of
      URLs, even small optimizations have significant impact.

   *  Future-Proofing the Web: Adopting `s://` aligns with the long-term
      goal of deprecating insecure HTTP connections entirely.

4.  Challenges & Mitigations

   *  Adoption Resistance: Gradual adoption with backward compatibility
      ensures a smooth transition.

   *  Legacy Systems: Legacy systems can continue using `http://` or
      `https://` until phased out.

   *  Awareness: Collaborate with industry leaders, browser vendors, and
      developers to promote the change.

5.  IANA Considerations

   This document requests the registration of the `s://` scheme in the
   Uniform Resource Identifier (URI) Schemes registry [RFC9110].





Ranalvi                   Expires 28 July 2025                  [Page 3]

Internet-Draft        `s://` as a Secure URL Scheme         January 2025


6.  Security Considerations

   The introduction of `s://` does not alter the underlying security
   model of HTTPS [RFC9110].  It is essential that implementations
   ensure `s://` is interpreted as a secure connection using TLS
   [RFC8446].  Proper validation and error handling must be maintained
   to prevent misuse or vulnerabilities.

7.  References

7.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,
              <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>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

   [RFC9112]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022, <https://www.rfc-editor.org/info/rfc9112>.

   [RFC9114]  Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
              June 2022, <https://www.rfc-editor.org/info/rfc9114>.

Acknowledgements

   The author would like to acknowledge his parents (Abbas & Parveen),
   wife (Shaheen) and his two daughters (Zoya & Anaya) for their love
   and support, always.




Ranalvi                   Expires 28 July 2025                  [Page 4]

Internet-Draft        `s://` as a Secure URL Scheme         January 2025


Author's Address

   Ali Mohsin Ranalvi
   I-1006, Pristine Prolife 1, Shankar Kalate Nagar, Wakad
   Pune 411057
   Maharashtra
   India
   Email: ali.ranalvi@gmail.com











































Ranalvi                   Expires 28 July 2025                  [Page 5]