Internet security is a "real-world issue". The recent outbreak
of the "Melissa" virus is a good example where some product manager
paid attention to what they heard users asking for, only
to discover later the serious consequences of ignoring sound
engineering. (The IETF standard for email attachments contains
a detailed discussion of the security considerations of allowing
email attachments to execute code in the recipient's environment.)
The users may not actually know the consequences
of what they're asking for, and it is irresponsible to design
a standard with inadequate security merely because your product
managers are unable to think through the consequences of the
decisions you're promoting.
Anyone who doesn't think this is a "real world" issue has been
living under a rock.
> To require mandatory support for N different authentication or
> encryption standards will not sit well with implementors or end-users.
We should require mandatory support for a minimum number of
authentication and encryption standards. I was suggesting that
we require one mandatory authentication scheme: digest
authentication with qop=auth and encryption=MD5 or MD5-sess.
(So I suppose that's two variants, rather than just one.)
> OTOH, if you give us a choice of options that meet the different needs
> and require support for at least one of them, then I think you'll get
> much more support from folks in general while still meeting the goals
> set forth by the IETF.
Unfortunately, if you make things options and allow negotiation of
the options, you open up another security risk; a MITM attack that
downgrades the requested server security. So it's counterproductive
to have "options" with _less_ protection. It would be fine to
allow TLS (or SSL3, even) as options, presuming that the required
level of authentication protection is as good or better than
encryption=MD5 with Digest. Allowing 40 bit encryption with
Basic authentication, though, is a step down, and shouldn't be allowed
as a negotiable option.
Larry