From: "Amanda Walker" <amanda@intercon.com>
Date: Tue, 13 Dec 94 09:06:00 PST
To: cypherpunks@toad.com
Subject: Re: HTTP security
Message-ID: <9412131206.AA35070@amanda.dial.intercon.com>
MIME-Version: 1.0
Content-Type: text/plain


> Actually, it's EIT. EInet is an MCC (the people who did MacWeb, not to 
> be confused with MCOM, the people who did Netscape. Confusing, ain't 
> it?) project. 

I think I'm starting to need a quick reference card :).

> When a server replies to one of my requests, 
> we have definitely exchanged at least one message. 
> Now, assume for the moment that my request was encrypted and that I 
> desire confidentiality for the reply. There is no need for the server 
> to perform public key crypto because we've had the opportunity to 
> exchange a key already. This means a substantial performance 
> improvement. [It incidentally means that a server and I can 
> communicate privately even if I don't have a key pair]. 

This is true.

Just as an exercise, I'll give a description of the informal model that I have 
been using as I evaluate different proposals for secure HTTP (and other 
Internet security proposals).

(1) I trust the network somewhat more than I trust the server machine.

    This is why I don't like SSL, for example.  Now, I realize that this
    assumption is not a universal (someone in a college dorm would trust
    the server a lot more than the network), but the fact is that once you
    get off your organizational Ethernet, it's hard to monitor the Internet.
    On the other hand, servers are a problem.  If someone's running a web
    page on Netcom, for example, I don't want to have to worry about whether
    or not they've been broken into this week (note that I'm using Netcom
    strictly as an example--the same concern holds for any public access
    system).  I want to be able to authenticate the content I am viewing
    without having to worry about whether or not the transport & server
    systems have been compromised.  I'm still vulnerable to a denial of
    service attack, of course, but at least I can tell when I do get something
    that it is genuine.  This concern holds even when I don't care if the
    content is encrypted.  If I get sales literature, I want it signed by
    the organization it claims to be from, and so on.  And for this purpose,
    I like X.509.  Self-signed certificates are fine, if there are other
    ways to verify the public key.  Signed PGP keys could be used as
    certificates as well, of course.

(2) I want authenticated content all the time, even if it's just to an
    anonymous key pair I've gotten through some other channel.

(3) I want private content sometimes.  When I want private content, I want
    end-to-end privacy, not just transport level privacy.

(4) Occasionally, I want transaction security (sending a credit card order,
    for example), where I want the transaction to be encrypted, signed, and
    not subject to playback attacks.  Ideally, the server itself won't be
    able to decrypt it--only the actual recipient will.

In all cases, I expect the network and the server machines and software to be 
insecure.  Anything else is simply unrealistic.


Amanda Walker