Re: MIME Multipart security?

In thinking about this some, we could get ourselves into quite a bit of 
trouble by trying to solve the wrong problem.  When the problem is that 
a protocol lacks a capability, then the IETF needs to get involved. 
When the problem is the UI, fix the UI  -- AND ANY UNDERLYING 
INFRASTRUCTURE IT REQUIRES.

UIs can require significant redesign in order to make use of a 
particular mechanism.  For example, we had a product that we attempted 
to transition into COPS-PR, and we were told by UI experts that  because 
of the different levels of abstraction, there was no way to have a UI 
that uses both COPS-PR and the previous mechanism in which they would 
both work in an intuitive fashion.

Now, this certainly had implications for the COPS-PR protocol.  Assuming 
others ran into the same problem, there was no way to migrate legacy 
applications.  But here's the key: not a single person in the IETF 
identified this as a showstopper.  And why should we have?  We don't 
have the expertise in user interface design.

Now here we are worrying about user interfaces and the lack of market 
uptake in end to end messaging security.  It could well be that we 
haven't found the RIGHT UI.  But how can we tell?  We might even have 
the right mechanisms, but that they are not well organized to a user's 
liking.  Again, it's like playing a lawyer on the 'net.

Just some thoughts...

Eliot



Chris Newman wrote:

> 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 Saturday, 9 November 2002 14:08:59 UTC