Notes from Secure HTTP Review Meeting at MIT

1 November 1994
Notes by Win Treese (treese@OpenMarket.com)

The purpose of these notes is to capture the flow of the discussion
as it happened, not to be a coherent review of security and the
World-Wide Web.

Present:
Marc Andreesson (Mosaic Communications)
Tim Berners-Lee (MIT LCS)
Adam Cain (NCSA)
Phill Hallam-Baker (CERN)
Jeff Hostetler (Spyglass)
Danny Mayer (Digital)
John Klensin (MCI)
Allan Schiffman (EIT)
Win Treese (Open Market)
Unable to attend
Vint Cerf (MIT)
Dave Clark (MIT LCS)
Ron Rivest (MIT LCS)

Handed out during the afternoon:
An Architecture for Security in LibWWW for WWW Clients (TR-105)
Jeff Hostetler, Spyglass
The SSL Protocol
Kipp Hickman, Mosaic Communications Corp.
(SSL = Secure Sockets Layer)
Secure HTTP
Allan Schiffman, EIT

The meeting began with introductions. To get things started, Berners-Lee
listed several possible requirements for security and the Web (some of
these were added as the meeting progressed):

The protocol should be:

1. Useable by any TCP protocol (this from Mosaic Communications, as in SSL)
2. Able to encrypt at any level (the issue here is that public-key
cryptography is computationally expensive, so it should be applied
only when necessary)
3. Backwards compatible (this from Vint Cerf). Possible ways to allow
this include using negotiation, different port numbers, or different
protocol designators in URLs to distinguish the old from the new.
4. Above the transport layer provided by TCP
5. Capable of streaming
6. which side (client or server) determines the security used?
7. Pluggable (from Vint Cerf). That is, the security subsystem should
be designed so alternative components (e.g., different cryptosystems)
can be used.
8. Exportable (from Vint Cerf). It was observed that this can be difficult,
and exportability from the U.S. is not the only legal issue for use.
9. Simple (Andreesson)
10. Common base case ("least common denominator") (Andreesson)
11. Able to work with proxy servers
12. Able to work using replicated servers

Because HTTP is a transaction-oriented protocol, we discussed the need
for "security associations" that span more than one HTTP connection.

Berners-Lee drew the following diagram on the board, with suggestions from
the group:

Trust Model
|
|
V
Security "Quality of Service" (OSI-speak)
|
|
V
|-------------| |-------------|
Initial | | | |
state --->| Negotiation |-->| Payload des information about security protocols
which the client or server is capable of using.
- Each document has an associated security policy.
- The server selects a common protocol for sending a document.
If no common protocol is satisfactory for the server, it
can return an HTTP 401 or 402 Not Authorized message, with the
HTTP header specifying acceptable security protocols.

Berners-Lee noted that both sides have security abilities and
requirements, and this information could be specified in several
different places (URL, URN, HTTP, etc.)

Schiffman said that this very general model fits in well with EIT's
Secure HTTP specification.

We discussed the importance of compatibility with Privacy-Enhanced
Mail (PEM). The primary advantage is the use of existing code,
although Schiffman pointed out that some software vendors could
benefit from reduced licensing fees by reusing PEM code.

We discussed the ins and outs of US export regulations. Berners-Lee
pointed out that interopeinteroperability need to be specified: authentication (including key
exchange) and encryption.

Klensin: Both sides need to be able to understand when something goes
wrong, and why.

HTTP implementations today ignore headers that they do not
recognize. This can cause problems with security if one side blindly
proceeds after ignoring security headers. One proposed solution is to
add a header that says "You must be able to understand the following
headers to proceed".

Previous Work
-------------

Andreesson, Schiffman, Hostetler, and Hallam-Baker presented their
respective proposals. Descriptions of the proposals, with the
exception of Shen, were passed out, so I won't go into the details of
the proposals here except for points of discussion.

SSL
---

SSL uses X.509 certificates during setup and key
exchange. Hallam-Baker suggested that certificates should include
additional attributes. Schiffman: X.509-1993 does, but it provides no
interpretation for the added attributes. Because a user might want to
choose which certificate to use from a set, the current SHTTP clients
allows the user to specify properties of the desired certificate using
pattern matching.

Hallam-Baker suggested that certificates might be retrieved using
embedded links, which led to a general discussion of how to make it
possible for programs to interpret additional attributes (e.g., "Jones
has purchasing authority for items up to $1000"). Schiffman suggested
that PKCS-6 provided an extensible superset of X.509-88 certificates
that might be useful for this purpose. Hallam-Baker wanted to make it
possible to use many different certificate formats.

Schiffman asked about using proxies with SSL; Andreesson said that the
real client's IP address needed to included with the SSL header for
this to work.

We then discussed whether or not the protocol should be printable
ASCII or binary. SSL uses a binary protocol. Klensin noted that
binary protocols are nearly impossible to use for store-and-forward
systems because of filesystem differences, and that a traditional
objection to binary protocols is that they are harder to debug.

Secure HTTP

It was noted that the new MIME-PEM specification has everything that SHTTP needs except a binary encoding.

Security in LibWWW

Schiffman raised some issues about payment in this proposal:
	1. What happens when payment charges change based on identity?
		(e.g., discount for AAA members)
	2. How should payment operations be encoded? Do we need
	   boolean operations for specifying options?  For example,
	   how wtler's proposal)
		protocol type
		interleaved type

but this was not nailed down.

We also discussed what should be in a W3C specification for
security. In addition to the basic protocol, there should be a
document for each security mechanism that descirbes its goals,
assumptions, risks, acceptable (i.e., appropriate, legal, etc.) uses,
proof (using techniques like Burrows-Abadi-Needham logic), and mapping
to HTTP.  It is important for users to understand these items.

Andreesson asksed how many security schemes are really expected in
practice?

Other Systems
-------------

Treese gave a quick overview of the Open Market payment system, which
overloads URLs with digitally signed attributes to carry payment and
access information.

Cain asked whether or not the IETF's GSS API was relevant.

Schiffman described an integrity attack on SSL, in which the attacker
inserts random data into the stream.

Shen
----

Hallam-Baker described his work on Shen (see
http://cayenne.lcs.mit.edu/peoplligious case" for the SSL
approach, since one can then run anything on top of it.  He asked if
there was added value by using SHTTP to simulate an encrypted stream.

Schiffman agreed to write a profile describing how SHTTP can provide
the semantics of SSL, and said he thought that it would be possible to
fold in some of Hostetler's proposal into SHTTP.

Remaining questions:
	- Should MIME be used?
	- Can the negotiation mechanisms be specified independently
	  from the rest of SHTTP?
	- Should the security protocols use a binary encoding?