Internet DRAFT - draft-farah-uggc-protocol
draft-farah-uggc-protocol
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
<URL:http://www.my.example/docs/misc/index.html>, the
encrypted URL becomes:
<URL:uggc://jjj.zl.rknzcyr/qbpf/zvfp/vaqrk.ugzy>.
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
<URL:uggc://jjj.zl.rknzcyr/docs/misc/index.html>.
- 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
<URL:uggc://jjj.zl.rknzcyr/qbpf/zvfp/index.html>. However,
<URL:uggc://jjj.zl.rknzcyr/qbpf/misc/index.html> 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 <URL:uggc://jjj.zl.example/docs/misc/index.html>, 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
<URL:uggc://www.my.example/docs/misc/index.html>.
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
<URL:http://www.my.example/Misc/Here/Hello.html> 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, <URL:uggc://jjj.rknzcyr.rqh/~aubea> 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, <URL:uggc://jjj.zl.rknzcyr/dhrel.ugzy?anzr=Zvthry> 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 <URL:uggc://jjj.zl.rknzcyr/Zvfp/Urer/Uryyb.ugzy>
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]
