Re: HTTP security

[ekr@eit.COM (Eric Rescorla)]

See what happens when you call my name (or at least try to...)
James is >
Amanda is >>
>> This seems a very relevant criticism:  Has Amanda, or anyone else 
>> proposed an extension to HTML that would incorporate such things? 
>Actually, it's not an extension to HTML, but to MIME (whose formats HTTP uses 
>top tag and label data), and it just went to Proposed Standard (the last step 
>before Internet Standard).  The MIME multipart/signed and multipart/encrypted 
>body parts allow anything using MIME encapsulation to sign and/or encrypt 
>arbitrary body parts.  Since it's at the document layer, it requires no 
>special transport software, works with existing proxies and caching servers, 
>and allows secure HTTP software to share code with secure email software 
>(since it would use exactly the same formats).  The framework is general 
>enough to allow use with either PEM-compliant signatures and encryption or 
>others (such as PGP).  I believe that can also be used with symmetric key 
>management, which could be useful for special purpose applications.
Uh, PEM-MIME no longer supports symmetric key management.

>EInet's secure SHTTP proposal is also an end-to-end security framework.
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.

Anyway, the approach that Amanda describes is pretty much the
one that SHTTP takes. We use already established encapsulation
formats to do data encapsulation. SHTTP can be used to enhance
either entire protocol messages or objects or both. (You can
do both in the same message using a recursive encapsulation).

I think Amanda has done an adequate job of talking about
end to end security, so I won't talk about that. I would like
to briefly motivate why just using PEM-MIME isn't enough, though.
(We considered it and believe me it would have been a lot easier
on our brains and fingers...)

PEM-MIME and to a lesser extent PGP are basically cryptographic
messaging formats intended for email type applications. However,
the email model is fundamentally different from the Web model
in a number of ways. Let me just give one example:

In the email world, you don't necessarily have any sort of prior
relationship with the person you're communicating with and that public
key cryptography is relatively cheap. (When it takes minutes to
ship mail across the net, who's going to notice a second or two
of signature verification?) However, in the case of the Web,
things are very different. 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].

When I say that just PEM-MIME is inadequate, I don't mean to imply
that using it is inadequate, however. On the contrary, we use
PEM and PKCS7 already and are gearing up to include PEM-MIME, now
that it's going to proposed standard. [Incidentally, there's no reason
you couldn't use PGP too, although I propose that it's most useful in
the proposed PGP-MIME multiparts...] And you should be able to reuse
your PEM-MIME engines to write SHTTP handlers. It's just that we
also took on some issues that we thought were important that we
couldn't steal solutions for..

-Ekr