Re: MIME Multipart security?

begin  quotation by Dave Crocker on 2002/11/7 22:36 -0800:
> The UI problem is difficult.  And certainly the products I have seen
> are not easy enough to use.  I'm not sure there is much the IETF can
> do about that, though, unless we can devise a cert scheme that
> naturally creates an easy user scenario.
>
> Offhand, I'd suggest that both email and the web have in fact done
> just that. The basic model for each of them is wonderfully simple. Can
> we say the same for PGP or S/MIME?  Or at least for an acceptable cert
> mechanism?

The problem is that the majority market is not willing to compromise much 
in the way of usability in order to attain security (and rightly so, IMHO). 
And there are only two security user interfaces that have proven to be 
widely deployable: username/password entry forms and smart cards that "just 
work" like house keys or car keys.  I predict that any public-key scheme 
which fails to present one of those two user interfaces as the default user 
interface in the majority of products will be a failure in the general 
market.

> SASL is popular.  Would that we could have such a security negotiation
> framework for store-and-forward object security.  Alas, trying to
> "negotiate" in store and forward is rather difficult, as the
> email-based use of CONNEG is demonstrating.

Be aware that SASL does not solve the problem of "mandatory-to-implement 
interoperable security that's better than unencrypted plaintext passwords". 
I worked for years to determine the best answer to that problem, and came 
up with two reasonable options: TLS+plaintext passwords and DIGEST-MD5 (the 
market leans heavily towards the former, but the latter does offer a useful 
cheap alternative and the combination of both is interesting).

What makes SASL popular is there are so many connection-based 
authentication mechanisms (most of which can be presented as a 
username/password entry form) which provide valuable tradeoffs, that the 
abstraction layer is vital.  I'd say all of the following SASL mechanisms 
have characteristics that make them worth using in some scenarios: PLAIN, 
DIGEST-MD5, CRAM-MD5, OTP, Kerberos, SRP, SecureID.  Plus it would be 
possible to develop a few more that would also fill useful market niches.

> But SASL is not just a negotiation framework.  It is a common
> representation framework.  Would it help to have that for MIME?
>
> Oh.  We do.  That's what Multipart MIME Security was intended to be.
> The problem is that it isn't used much or at all by the two standards.

I'm somewhat dubious of the value of Multipart MIME Security.  Because 
object-security is most useful in an enviornment where negotiation is not 
an option, the number of useful fundamental mechanisms I can think of ends 
up in the 2-3 range rather than the 8-12 range.

> The other is to revive the simple PKI effort, to get a basic mechanism
> that supports only a core set of cert functionality -- rather than the
> cornucopia of policies that have been pursued -- and that scales but
> is real, real easy to use.

A major problem is that the customers who pay real money for 
top-of-the-line object security have already choosen S/MIME and have little 
interest in any alternative.  That leaves most large companies with no will 
to expend resources on the larger problem of deployable object security.

While it would be entertaining to try a 4th attempt at application-level 
object security (preferably this time with more input from application 
experts and less from security purists), I think the odds of succeeding 
have decreased significantly since the last 3 attempts.  If you really 
wanted to pursue this direction, here's what I think it would take to 
succeed:
1) Really good open-source implementations with free-for-commercial use 
license, at least one in C and one in Java.
2) Transition strategy from existing PKI systems that works and is included 
in 1.
3) A really good spec, that includes good discussion about user interface 
requirements and how to deploy the system into an untrained average user 
community (likely involving automatic fetching of generated private keys 
over the Internet using TLS and a username/password pair).
4) A major vendor or consortium backing the effort with enough clout to get 
the attention of the trade rags.

Of these, 1 and 2 are just plain hard, 3 goes against IETF traditions 
enough that I think the IETF would be the wrong standards group to do this 
in, and 4 may be nearly impossible in the current business climate.

                - Chris

Received on Friday, 8 November 2002 14:48:22 UTC