Network Working Group M. Farah Request for Comments: nnnn T.I.A. Category: Experimental 1 April 2000 Encrypted Hypertext Transfer Protocol -- UGGC/1.0 draft-farah-uggc-protocol-00.txt Status of this Memo This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. ABSTRACT This memo defines an experimental protocol -called UGGC- that serves as an encrypted counterpart to HTTP. 1. Introduction It's a known fact that web surfing has become a much more important activity in the net than what was expected six years ago. Anti-prying measures have been taken in other services (mail encryption, for example), but haven't been in WWW: anyone can spy at what another user is browsing at the moment by intercepting his packets and looking at their content ("sniffing"). This document proposes a method that guarantees it won't happen anymore, by discouraging the act of sniffing. A new URL, 'uggc', is defined, which is a sort of twin brother to 'http'. The former works in the very same way as the latter does, with the following exception: both URLs and the data travelling from the client to the server and vice versa are encrypted. The data retrieved is equivalent, once decrypted back. 2. Description 2.1 Encryption algorithm used Both URLs and content transferred are to be encrypted/decrypted using the ROT13 mechanism. This encryption/decryption method is algorithmically simple (it's o(N), with N = length of the input in bytes), and has proven to be extremely powerful. Hell, it's been used for more than two millennia, and the ancients certainly knew what they were doing. 2.2 URL syntax and encryption methods URLs MUST be encrypted in one of the following ways: 1) total encryption: the entire URL is encrypted. For example, if one were to access , the encrypted URL becomes: . Farah Experimental [Page 1] Encrypted Hypertext Transfer Protocol 1 April 2000 2) partial encryption: there are two acceptable syntaxes: - the host part of the URL is encrypted, the rest is not. The previous example would now become . - the host part is encrypted, and so is the abs_path up to but not including the file name and arguments passed as parameters, if any. The abs_path MUST NOT be encrypted only in part. The previous example becomes . However, does NOT refer to the same URL, although it's syntactically valid and MAY yield an actual valid response. In both cases, the entire host part MUST be encrypted. So, an URL as , while syntactically valid, refers neither to the same URL as the example does, nor to the same server. 3) null encryption: the entire URL is NOT encrypted. The previous example becomes . The scheme part ("uggc://") itself is not encrypted as such, but rather has a different name (than "http://", of course) in order to distinguish one protocol from the other. In all cases, arguments passed within a URL MAY or MAY NOT be encrypted, depending on the method used (total, partial or null). 2.3 User/client/server interaction The interaction between the user, the client and the server is the following: - the user tries to access an URL by inputting it to his/hers/its WWW client (take note that in this context, "the user" may be either a person or a process; processes like TRON MUST be taught to understand the blurring of this barrier between both kinds of entities, which was so marked during the time when MCP tried to attain supreme power). - the WWW client determines what site it has to make the request to, and then sends the UGGC request in the same manner as an HTTP one. The client is not expected to determine wether the user entered the rest of the URL with total, partial or null encryption, and MUST NOT alter it. Farah Experimental [Page 2] Encrypted Hypertext Transfer Protocol 1 April 2000 - the WWW server, upon reception of the request, MUST determine exactly what is being asked to return, process it, encrypt it with ROT13, and send it back to the client. - the WWW client receives the result, decrypts it, and then displays it to the user. This whole process MUST be transparent to the user, except for the detail of typing "uggc://" instead of "http://". If the user inputs an URL with the scheme part missing ("www.example.com", for example), the client MUST NOT assume the user meant the UGGC protocol, even if it's obviously encrypted. The client MAY issue a warning to the user telling him the HTTP protocol will be used. The data received by either protocol MUST be the same. For example, if accessing returns the string "Hello, World!", then the following URLs: - uggc://jjj.zl.rknzcyr/Zvfp/Urer/Uryyb.ugzy - uggc://jjj.zl.rknzcyr/Zvfp/Urer/Hello.html - uggc://jjj.zl.rknzcyr/Misc/Here/Hello.html - uggc://www.my.example/Misc/Here/Hello.html MUST also return the same string. A cracker sniffing this, though, will only see the string "Uryyb, Jbeyq!" and will end up extremely confused by what he'll believe to be gibberish. The WWW server (www.my.example) is expected to be able to determine wether "Zvfp/Urer/Uryyb.ugzy" means actually the file "Uryyb.ugzy" in the subdirectory "Urer" in the subdirectory "Zvfp", or the file "Hello.html" in the same place, or the file "Hello.html" in the subdirectory "Here" in the subdirectory "Misc". It is RECOMMENDED that the server doesn't have any directories with conflicting names (following the current example, the server SHOULD have either the "Misc" or the "Zvfp" directory in the root level, but not both). Among other things, this implies that the login assignation algorithms used in universities and some companies MUST be revised to take this into account, so personal WWW pages from different students and/or employees won't collide. For example, could refer to either Mr. Andoni Ubea's homepage or to Mr. Nigel Horn's one. Farah Experimental [Page 3] Encrypted Hypertext Transfer Protocol 1 April 2000 The WWW server is also expected to be able to determine wether any arguments passed within the URL are encrypted or not. For example, could either be passing the value "Zvthry" to the variable "anzr", or it could be passing the value "Miguel" to the variable "name". It has to be noted that the syntax forbids having only part of the arguments encrypted: either they're all encrypted or they're all unencrypted. 3. Resolution of conflicting site names Since an URL like may refer either to the server jjj.zl.rknzcyr or to the server www.my.example, confusions over which is the correct site to access are to be expected. 3.1 Three-lettered Top Level Domains The three-lettered top level domains (.com, .edu, .gov, .mil, .net and .org) have no conflicts among them, so this isn't an issue: possible server names with nonexisting TLDs are obviously wrong, and so the encrypted/unencrypted corresponding name must be the right one. In the future, when new top level domains are assigned, this MUST be taken into account (for example, a gambling-related top level domain MUST NOT be called ".bet", because that would provide a means of confusion with .org sites). 3.2 Country codes Top Level Domains These TLDs are two-lettered, taken from the ISO3166 specification for 2- and 3-letter country codes. In an incredible omission made by the ISO, UGGC compliance was not considered; this generates conflicts between several pairs of countries, whose encrypted codes are the same as others' unencrypted ones. Some examples of this phenomenon are: - Austria AT <=> NG Nigeria - Chile CL <=> PY Paraguay - China CN <=> PA Panama - Costa Rica CR <=> PE Peru - Finland FI <=> SV El Salvador - France FR <=> SE Sweden - India IN <=> VA Vatican City - Iran IR <=> VE Venezuela Farah Experimental [Page 4] Encrypted Hypertext Transfer Protocol 1 April 2000 3.3 A Method for inhibiting these conflicts The intuitive way of resolving this conflict would be to program the WWW client to contact BOTH possible sites, and see which one responds first. This approach is a waste of time and bandwidth, and does not resolve all possible situations: what if *both* possible servers DO answer? The best way to deal with this is to avoid the existence of more than one of those "possible" servers. To achieve this, the NICs of each respective country MUST agree on a procedure that will prevent this situation from happening. For example, if someone registers the "freire.cl" vanity domain in Chile ("Freire" is a rather common surname in this country), the Paraguayan NIC should forbid registering the "server.py" domain in its country from then on. With this conflict resolution scheme working, the WWW client will only have to do -at most- an extra DNS request, compared to the equivalent process using http. 3.4 Miscellaneous considerations WWW clients SHOULD use heuristics for making more efficient guesses about which of the two possible sites is the real one. For example, the client receives the site "jjj.zl.rknzcyr": it begins with "jjj.", so it's a pretty fair chance it is encrypted, and thus "www.my.example" (the decrypted site name) should be tried first. 4. Security considerations This whole protocol will be rendered useless if the ROT13 encryption mechanism is ever cracked. 5. Acknowledgments The author wishes to acknowledge Julius Caesar for his tremendous invention. 6. Author's address Miguel Farah Regina Pacis 1305 (Providencia) Santiago, Chile phone - +56 2 205 2208 email - miguel@webhost.cl Farah Experimental [Page 5]