Re: Security

[Sam Hartman <hartmans-ietf@xxxxxxx>]

>>>>> "Simon" == Simon Josefsson <simon@xxxxxxxxxxxxx> writes:

    Simon> We disagree on the principal here.  Merely because there
    Simon> are known vulnerabilities (which can be fixed by using
    Simon> TLS), that shouldn't prevent something to go on the
    Simon> standards track.  If that were the metric, we wouldn't
    Simon> publish SMTP on the standards track due to spam concerns.
    Simon> You make it sound as if only perfect protocols should be on
    Simon> the standards track.

I don't think I'd characterize things that way.  I think we should put
something on the standards track when we believe it is a good instance
of whatever it does.  There should be no significant vulnerabilities
that we can fix while it's still the same thing.

I think plain meets this criteria today.  In a few years, I suspect
we'll decide that phishing concerns are more important than the
ability to support plaintext passwords over TLS.

In particular, plain is the best we can do while supporting legacy
password systems.

Cram-md5 is no longer a good instance of a challenge-response
mechanism.  The world has evolved and integrity/confidentiality
protection are important, as is mutual authentication all at one
layer.  As such, I think cram-md5 no longer meets good practice for
the design of a challenge-response mechanism, so we should not
recommend it.

Note that my arguments do not apply to digest-md5.  If people want to
update digest-md5 on the standards track, I will not stand in their
way.  I personally don't think it worth doing.


To come back to your example of SMTP, I think if we had viable
proposal for an email transport that did not have spam concerns, we
should seriously question whether SMTP should remain on the standards
track.  I'm aware of no such proposals.