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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . [RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, . [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . 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]