- From: Chris Newman <Chris.Newman@Sun.COM>
- Date: Thu, 07 Nov 2002 12:27:04 -0800
- To: Dave Crocker <dcrocker@brandenburg.com>, Paul Hoffman / IMC <phoffman@imc.org>
- Cc: discuss@apps.ietf.org
begin quotation by Dave Crocker on 2002/11/7 10:59 -0800: > I did not make or imply any such recommendation. > > Yes, I said that juggling two is a problem. > > But I also said that the market is clearly unwilling to choose one. > > Therefore having the IETF try to choose one is both arbitrary and > contrary. > > There is no clear basis for making a global choice for one of them. And > there is clear market feedback that neither is preferred by a rough > consensus of that market. > > A standards group that ignores market feedback is a standards group that > is irrelevant to the market. Sometimes markets do stupid things. So as a general principle, a standards group should be aware of how things are faring in the market, but a standards group which cares about technical excellence should not always follow to the market. Standards groups can and should push the market to do better technically where it is feasible. Security, in particular, is one area where the standards should lead the market because markets have a tendancy not to demand security until it is too late to deploy it. That said, I happen to think both PGP and S/MIME are currently failures. PGP has only deployed significantly in the individual geek market. S/MIME has only deployed significantly in security-sensitive companies and government offices. By "deployed", I mean end-users actually use it rather than products ship with support for it. My speculation of why both PGP and S/MIME are failures in the larger market is that the concept of client certificates is simply too complex or cumbersome for the average end-user absent a deployed global smart-card standard. But it could also be because the standards haven't placed sufficient requirements on user interfaces and the bootstrap problem or that the products to date haven't focused enough on usability to be actually usable by the average end-user. So where does that leave us? If the IETF produces a hop-to-hop protocol which can transport non-public data and wants it to be technically competent, we must require some sort of interoperable security that's better than unencrypted plain text passwords. But the two standards track protocols we have for object security are currently failures and I agree with Dave that they are unreasonable to mandate. Personally, I think the answer is that whenever the IETF produces a hop-to-hop protocol we mandate the use of a hop-to-hop layer which provides a deployable security mechanism such as TLS with plaintext passwords, or an SSH-style Diffie-Hellman exchange. In theory, it doesn't provide as good security as S/MIME or PGP/MIME, but in practice it provides better security because it will deploy and be used in the larger market. But we do need to allow for optional S/MIME and PGP/MIME security because I believe a global smart card standard will deploy eventually and then they will be an improvement over what we can deploy now. - Chris
Received on Thursday, 7 November 2002 20:23:52 UTC